https://glossar.hs-augsburg.de/w/api.php?action=feedcontributions&feedformat=atom&user=Lichten 2026-07-17T08:11:27Z Benutzerbeiträge MediaWiki 1.43.3 https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=12022 2008-07-08T16:06:50Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[http://www.infopark.de/ Infopark CMS Fiona]<br /> *[http://www.reddot.de/ RedDot]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Vergleich LiveServer – Publishing-/Staging-Server|Vergleich LiveServer – Publishing-/Staging-Server]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=12021 2008-07-08T16:06:20Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[[Joomla!|Joomla!]]<br /> *[http://www.xist4c.de/ XIST4C]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> *[[Vergleich LiveServer – Publishing-/Staging-Server|Vergleich LiveServer – Publishing-/Staging-Server]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12020 2008-07-08T16:02:58Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein [[Live-Server|Live-Server]] hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Skalierbarkeit=<br /> Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem [[Live-Server|Live-Server]] muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.<br /> <br /> =Performance=<br /> Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines [[Publishing-/Staging-Server|Publishing-/Staging-Server]] kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des [[Publishing-/Staging-Server|Staging-Servers]] eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der [[Publishing-/Staging-Server|Publishing-Server]] erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem [[Live-Server|Live-Server]] auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden. <br /> <br /> =Ausfallsicherheit=<br /> Durch eine Trennung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]], kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des [[Publishing-/Staging-Server|Publishing-Servers]], der [[Publishing-/Staging-Server|Staging-Server]] immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein [[Live-Server|Live-Server]] ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.<br /> <br /> =Wartung=<br /> Auch bei der Wartung des Systems ist bei einem [[Live-Server|Live-Server]] die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei [http://www2.ebay.com/aw/marketing-de.shtml ebay.de] freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durchaus moderat. Wenn der [[Publishing-/Staging-Server|Staging-Server]] gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am [[Publishing-/Staging-Server|Publishing-Server]] können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.<br /> <br /> =Suchmaschinen=<br /> Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut [http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Google-Hilfe] indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]], bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem [[Live-Server|Live-Server]], welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie [http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm XIST4C] nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.<br /> <br /> =Hardware=<br /> Bei der Hardware tauchen die vermeintlich ersten Nachteile einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] auf, da hier zwei separate Systeme gekauft und administriert werden müssen. Bei einem [[Live-Server|Live-Server]] bedeutet dies nur den halben Aufwand. Gehen wir jedoch von einem System mit vielen Redakteuren aus, welches in einem bereits vorhanden Rechenzentrum betrieben wird, so ist der Kostenfaktor für zusätzliche Hardware und bereits verfügbares Personal vernachlässigbar.<br /> <br /> =Suche=<br /> Mittlerweile ist es für jeden vernünftigen Internetauftritt ein Muss, eine Suche über die verfügbaren Inhalte anzubieten. Die Suche in einem [[Live-Server|Live-Server]] kann meist ohne weitere Anstrengungen mit Hilfe der Suchmechanismen der Datenbank, in welcher die Inhalte hinterlegt sind, umgesetzt werden. Da aber ein [[Publishing-/Staging-Server|Staging-Server]] per Definition keine direkte Verbindung zum Content Repository des [[Publishing-/Staging-Server|Publishing-Servers]] haben soll, muss hier eine gesonderte Lösung der Suche eingesetzt werden. Ein Ansatz ist, den Index über die Suchinhalte beim Export zu erstellen und diesen auf dem [[Publishing-/Staging-Server|Staging-Server]] mit einem eigenständigen Modul anzusprechen.<br /> <br /> =Personalisierung=<br /> Auch die Personalisierung kann mit leichtem Vorteil für das [[Live-Server|Live-Server-System]] gewertet werden. Durch die oftmals schon integrierte Benutzerverwaltung in das System, lässt sich diese Funktionalität einfach und schnell umsetzen. Bei einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] muss dies wie die Suche gesondert behandelt werden. Meist wird eine auf dem [[Publishing-/Staging-Server|Staging-Server]] eigenständige Benutzerverwaltung realisiert. Dieser Workaround beinhaltet dann aber auch eine zusätzliche Datenhaltung der Benutzereinstellungen (z.B. in einer Datenbank) und damit auch eine Erweiterung der Funktionalität des „einfachen“ Webservers.<br /> <br /> =Aktualität=<br /> Der entscheidende Grund für ein [[Live-Server|Live-Server]] ist häufig die Aktualität der Daten. Durch den direkten Zugriff auf die eingepflegten Inhalte ist eine Veröffentlichung der Informationen in Echzeit möglich. Vor allem bei Warenwirtschaftssystemen im E-Commerce-Bereich, wie auch bei Online-Zeitungen ist diese Eigenschaft unabdinglich. Man könnte dies auch auf einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] nachbilden, indem man ununterbrochen einen Export der neuen und/oder aktualisierten Inhalte durchführt. Da dies jedoch die Performance des [[Publishing-/Staging-Server|Publishing-Servers]] dauerhaft reduziert und beispielsweise bei der Suche auch der Index immerzu aktualisiert bzw. neu erzeugt werden muss, kann dies nicht als angebrachter Workaround gewertet werden.<br /> <br /> =Auflistung der Vor- und Nachteile=<br /> &amp;nbsp; <br /> <br /> {| cellpadding=&quot;3&quot; cellspacing=&quot;2&quot; style=&quot;font-weight:bold;&quot;<br /> |- style=&quot;vertical-align:top;&quot; align=&quot;center&quot; <br /> | width=&quot;130px&quot; |<br /> | width=&quot;180px&quot; style=&quot;background-color:#D4D4D4;&quot; | [[Live-Server|Live-Server]] <br /> | width=&quot;180px&quot; style=&quot;background-color:#D4D4D4;&quot; | [[Publishing-/Staging-Server|Publishing-/Staging-Server]]<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Sicherheit|Sicherheit ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Skalierbarkeit|Skalierbarkeit ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Performance|Performance ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Ausfallsicherheit|Ausfallsicherheit ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Wartung|Wartung ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Suchmaschinen|Suchmaschinen ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | o <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Hardware|Hardware ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Suche|Suche ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Personalisierung|Personalisierung ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Aktualität|Aktualität ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | –<br /> |}<br /> <br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Indexierung von dynamischen Inhalten bei Google]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12019 2008-07-08T15:58:23Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein [[Live-Server|Live-Server]] hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Skalierbarkeit=<br /> Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem [[Live-Server|Live-Server]] muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.<br /> <br /> =Performance=<br /> Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines [[Publishing-/Staging-Server|Publishing-/Staging-Server]] kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des [[Publishing-/Staging-Server|Staging-Servers]] eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der [[Publishing-/Staging-Server|Publishing-Server]] erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem [[Live-Server|Live-Server]] auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden. <br /> <br /> =Ausfallsicherheit=<br /> Durch eine Trennung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]], kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des [[Publishing-/Staging-Server|Publishing-Servers]], der [[Publishing-/Staging-Server|Staging-Server]] immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein [[Live-Server|Live-Server]] ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.<br /> <br /> =Wartung=<br /> Auch bei der Wartung des Systems ist bei einem [[Live-Server|Live-Server]] die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei [http://www2.ebay.com/aw/marketing-de.shtml ebay.de] freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durchaus moderat. Wenn der [[Publishing-/Staging-Server|Staging-Server]] gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am [[Publishing-/Staging-Server|Publishing-Server]] können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.<br /> <br /> =Suchmaschinen=<br /> Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut [http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Google-Hilfe] indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]], bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem [[Live-Server|Live-Server]], welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie [http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm XIST4C] nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.<br /> <br /> =Hardware=<br /> Bei der Hardware tauchen die vermeintlich ersten Nachteile einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] auf, da hier zwei separate Systeme gekauft und administriert werden müssen. Bei einem [[Live-Server|Live-Server]] bedeutet dies nur den halben Aufwand. Gehen wir jedoch von einem System mit vielen Redakteuren aus, welches in einem bereits vorhanden Rechenzentrum betrieben wird, so ist der Kostenfaktor für zusätzliche Hardware und bereits verfügbares Personal vernachlässigbar.<br /> <br /> =Suche=<br /> Mittlerweile ist es für jeden vernünftigen Internetauftritt ein Muss, eine Suche über die verfügbaren Inhalte anzubieten. Die Suche in einem [[Live-Server|Live-Server]] kann meist ohne weitere Anstrengungen mit Hilfe der Suchmechanismen der Datenbank, in welcher die Inhalte hinterlegt sind, umgesetzt werden. Da aber ein [[Publishing-/Staging-Server|Staging-Server]] per Definition keine direkte Verbindung zum Content Repository des [[Publishing-/Staging-Server|Publishing-Servers]] haben soll, muss hier eine gesonderte Lösung der Suche eingesetzt werden. Ein Ansatz ist, den Index über die Suchinhalte beim Export zu erstellen und diesen auf dem [[Publishing-/Staging-Server|Staging-Server]] mit einem eigenständigen Modul anzusprechen.<br /> <br /> =Personalisierung=<br /> Auch die Personalisierung kann mit leichtem Vorteil für das [[Live-Server|Live-Server-System]] gewertet werden. Durch die oftmals schon integrierte Benutzerverwaltung in das System, lässt sich diese Funktionalität einfach und schnell umsetzen. Bei einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] muss dies wie die Suche gesondert behandelt werden. Meist wird eine auf dem [[Publishing-/Staging-Server|Staging-Server]] eigenständige Benutzerverwaltung realisiert. Dieser Workaround beinhaltet dann aber auch eine zusätzliche Datenhaltung der Benutzereinstellungen (z.B. in einer Datenbank) und damit auch eine Erweiterung der Funktionalität des „einfachen“ Webservers.<br /> <br /> =Aktualität=<br /> Der entscheidende Grund für ein [[Live-Server|Live-Server]] ist häufig die Aktualität der Daten. Durch den direkten Zugriff auf die eingepflegten Inhalte ist eine Veröffentlichung der Informationen in Echzeit möglich. Vor allem bei Warenwirtschaftssystemen im E-Commerce-Bereich, wie auch bei Online-Zeitungen ist diese Eigenschaft unabdinglich. Man könnte dies auch auf einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] nachbilden, indem man ununterbrochen einen Export der neuen und/oder aktualisierten Inhalte durchführt. Da dies jedoch die Performance des [[Publishing-/Staging-Server|Publishing-Servers]] dauerhaft reduziert und beispielsweise bei der Suche auch der Index immerzu aktualisiert bzw. neu erzeugt werden muss, kann dies nicht als angebrachter Workaround gewertet werden.<br /> <br /> =Auflistung der Vor- und Nachteile=<br /> <br /> {| cellpadding=&quot;3&quot; cellspacing=&quot;2&quot; style=&quot;font-weight:bold;&quot;<br /> |- style=&quot;vertical-align:top;&quot; align=&quot;center&quot; <br /> | width=&quot;130px&quot; |<br /> | width=&quot;180px&quot; style=&quot;background-color:#D4D4D4;&quot; | [[Live-Server|Live-Server]] <br /> | width=&quot;180px&quot; style=&quot;background-color:#D4D4D4;&quot; | [[Publishing-/Staging-Server|Publishing-/Staging-Server]]<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Sicherheit|Sicherheit ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Skalierbarkeit|Skalierbarkeit ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Performance|Performance ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Ausfallsicherheit|Ausfallsicherheit ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Wartung|Wartung ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | – <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Suchmaschinen|Suchmaschinen ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | o <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | +<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Hardware|Hardware ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Suche|Suche ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Personalisierung|Personalisierung ]]<br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#E9E9E9;&quot; align=&quot;center&quot; | o<br /> |-<br /> | style=&quot;background-color:#D4D4D4;&quot; | [[Vergleich LiveServer – Publishing-/Staging-Server#Aktualität|Aktualität ]]<br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | + <br /> | style=&quot;background-color:#F2F2F2;&quot; align=&quot;center&quot; | –<br /> |}<br /> <br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Indexierung von dynamischen Inhalten bei Google]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12018 2008-07-08T09:19:21Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein [[Live-Server|Live-Server]] hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Skalierbarkeit=<br /> Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem [[Live-Server|Live-Server]] muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.<br /> <br /> =Performance=<br /> Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines [[Publishing-/Staging-Server|Publishing-/Staging-Server]] kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des [[Publishing-/Staging-Server|Staging-Servers]] eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der [[Publishing-/Staging-Server|Publishing-Server]] erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem [[Live-Server|Live-Server]] auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden. <br /> <br /> =Ausfallsicherheit=<br /> Durch eine Trennung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]], kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des [[Publishing-/Staging-Server|Publishing-Servers]], der [[Publishing-/Staging-Server|Staging-Server]] immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein [[Live-Server|Live-Server]] ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.<br /> <br /> =Wartung=<br /> Auch bei der Wartung des Systems ist bei einem [[Live-Server|Live-Server]] die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei [http://www2.ebay.com/aw/marketing-de.shtml ebay.de] freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durchaus moderat. Wenn der [[Publishing-/Staging-Server|Staging-Server]] gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am [[Publishing-/Staging-Server|Publishing-Server]] können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.<br /> <br /> =Suchmaschinen=<br /> Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut [http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Google-Hilfe] indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]], bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem [[Live-Server|Live-Server]], welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie [http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm XIST4C] nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.<br /> <br /> =Hardware=<br /> Bei der Hardware tauchen die vermeintlich ersten Nachteile einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] auf, da hier zwei separate Systeme gekauft und administriert werden müssen. Bei einem [[Live-Server|Live-Server]] bedeutet dies nur den halben Aufwand. Gehen wir jedoch von einem System mit vielen Redakteuren aus, welches in einem bereits vorhanden Rechenzentrum betrieben wird, so ist der Kostenfaktor für zusätzliche Hardware und bereits verfügbares Personal vernachlässigbar.<br /> <br /> =Suche=<br /> Mittlerweile ist es für jeden vernünftigen Internetauftritt ein Muss, eine Suche über die verfügbaren Inhalte anzubieten. Die Suche in einem [[Live-Server|Live-Server]] kann meist ohne weitere Anstrengungen mit Hilfe der Suchmechanismen der Datenbank, in welcher die Inhalte hinterlegt sind, umgesetzt werden. Da aber ein [[Publishing-/Staging-Server|Staging-Server]] per Definition keine direkte Verbindung zum Content Repository des [[Publishing-/Staging-Server|Publishing-Servers]] haben soll, muss hier eine gesonderte Lösung der Suche eingesetzt werden. Ein Ansatz ist, den Index über die Suchinhalte beim Export zu erstellen und diesen auf dem [[Publishing-/Staging-Server|Staging-Server]] mit einem eigenständigen Modul anzusprechen.<br /> <br /> =Personalisierung=<br /> Auch die Personalisierung kann mit leichtem Vorteil für das [[Live-Server|Live-Server-System]] gewertet werden. Durch die oftmals schon integrierte Benutzerverwaltung in das System, lässt sich diese Funktionalität einfach und schnell umsetzen. Bei einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] muss dies wie die Suche gesondert behandelt werden. Meist wird eine auf dem [[Publishing-/Staging-Server|Staging-Server]] eigenständige Benutzerverwaltung realisiert. Dieser Workaround beinhaltet dann aber auch eine zusätzliche Datenhaltung der Benutzereinstellungen (z.B. in einer Datenbank) und damit auch eine Erweiterung der Funktionalität des „einfachen“ Webservers.<br /> <br /> =Aktualität=<br /> Der entscheidende Grund für ein [[Live-Server|Live-Server]] ist häufig die Aktualität der Daten. Durch den direkten Zugriff auf die eingepflegten Inhalte ist eine Veröffentlichung der Informationen in Echzeit möglich. Vor allem bei Warenwirtschaftssystemen im E-Commerce-Bereich, wie auch bei Online-Zeitungen ist diese Eigenschaft unabdinglich. Man könnte dies auch auf einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] nachbilden, indem man ununterbrochen einen Export der neuen und/oder aktualisierten Inhalte durchführt. Da dies jedoch die Performance des [[Publishing-/Staging-Server|Publishing-Servers]] dauerhaft reduziert und beispielsweise bei der Suche auch der Index immerzu aktualisiert bzw. neu erzeugt werden muss, kann dies nicht als angebrachter Workaround gewertet werden.<br /> <br /> =Auflistung der Vor- und Nachteile=<br /> <br /> {| width=&quot;500px&quot; cellpadding=&quot;3&quot; cellspacing=&quot;1&quot; <br /> |- style=&quot;vertical-align:top; background-color:#dddddd;&quot; align=&quot;center&quot; <br /> | || Live-Server || Publishing-/Staging-Server<br /> |-<br /> | Sicherheit <br /> | align=&quot;center&quot; | – <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Skalierbarkeit <br /> | align=&quot;center&quot; | – <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Performance <br /> | align=&quot;center&quot; | – <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Ausfallsicherheit <br /> | align=&quot;center&quot; | – <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Wartung <br /> | align=&quot;center&quot; | – <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Suchmaschinen <br /> | align=&quot;center&quot; | o <br /> | align=&quot;center&quot; | +<br /> |-<br /> | Hardware <br /> | align=&quot;center&quot; | + <br /> | align=&quot;center&quot; | o<br /> |-<br /> | Suche <br /> | align=&quot;center&quot; | + <br /> | align=&quot;center&quot; | o<br /> |-<br /> | Personalisierung <br /> | align=&quot;center&quot; | + <br /> | align=&quot;center&quot; | o<br /> |-<br /> | Aktualität <br /> | align=&quot;center&quot; | + <br /> | align=&quot;center&quot; | –<br /> |}<br /> <br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Indexierung von dynamischen Inhalten bei Google]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12017 2008-07-08T08:54:51Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein [[Live-Server|Live-Server]] hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Skalierbarkeit=<br /> Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem [[Live-Server|Live-Server]] muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.<br /> <br /> =Performance=<br /> Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines [[Publishing-/Staging-Server|Publishing-/Staging-Server]] kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des [[Publishing-/Staging-Server|Staging-Servers]] eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der [[Publishing-/Staging-Server|Publishing-Server]] erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem [[Live-Server|Live-Server]] auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden. <br /> <br /> =Ausfallsicherheit=<br /> Durch eine Trennung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]], kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des [[Publishing-/Staging-Server|Publishing-Servers]], der [[Publishing-/Staging-Server|Staging-Server]] immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein [[Live-Server|Live-Server]] ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.<br /> <br /> =Wartung=<br /> Auch bei der Wartung des Systems ist bei einem [[Live-Server|Live-Server]] die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei [http://www2.ebay.com/aw/marketing-de.shtml ebay.de] freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durchaus moderat. Wenn der [[Publishing-/Staging-Server|Staging-Server]] gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am [[Publishing-/Staging-Server|Publishing-Server]] können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.<br /> <br /> =Suchmaschinen=<br /> Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut [http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Google-Hilfe] indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]], bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem [[Live-Server|Live-Server]], welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie [http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm XIST4C] nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.<br /> <br /> =Hardware=<br /> Bei der Hardware tauchen die vermeintlich ersten Nachteile einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] auf, da hier zwei separate Systeme gekauft und administriert werden müssen. Bei einem [[Live-Server|Live-Server]] bedeutet dies nur den halben Aufwand. Gehen wir jedoch von einem System mit vielen Redakteuren aus, welches in einem bereits vorhanden Rechenzentrum betrieben wird, so ist der Kostenfaktor für zusätzliche Hardware und bereits verfügbares Personal vernachlässigbar.<br /> <br /> =Suche=<br /> Mittlerweile ist es für jeden vernünftigen Internetauftritt ein Muss, eine Suche über die verfügbaren Inhalte anzubieten. Die Suche in einem [[Live-Server|Live-Server]] kann meist ohne weitere Anstrengungen mit Hilfe der Suchmechanismen der Datenbank, in welcher die Inhalte hinterlegt sind, umgesetzt werden. Da aber ein [[Publishing-/Staging-Server|Staging-Server]] per Definition keine direkte Verbindung zum Content Repository des [[Publishing-/Staging-Server|Publishing-Servers]] haben soll, muss hier eine gesonderte Lösung der Suche eingesetzt werden. Ein Ansatz ist, den Index über die Suchinhalte beim Export zu erstellen und diesen auf dem [[Publishing-/Staging-Server|Staging-Server]] mit einem eigenständigen Modul anzusprechen.<br /> <br /> =Personalisierung=<br /> Auch die Personalisierung kann mit leichtem Vorteil für das [[Live-Server|Live-Server-System]] gewertet werden. Durch die oftmals schon integrierte Benutzerverwaltung in das System, lässt sich diese Funktionalität einfach und schnell umsetzen. Bei einer [[Publishing-/Staging-Server|Publishing-/Staging-Server-Architektur]] muss dies wie die Suche gesondert behandelt werden. Meist wird eine auf dem [[Publishing-/Staging-Server|Staging-Server]] eigenständige Benutzerverwaltung realisiert. Dieser Workaround beinhaltet dann aber auch eine zusätzliche Datenhaltung der Benutzereinstellungen (z.B. in einer Datenbank) und damit auch eine Erweiterung der Funktionalität des „einfachen“ Webservers.<br /> <br /> =Aktualität=<br /> Der entscheidende Grund für ein [[Live-Server|Live-Server]] ist häufig die Aktualität der Daten. Durch den direkten Zugriff auf die eingepflegten Inhalte ist eine Veröffentlichung der Informationen in Echzeit möglich. Vor allem bei Warenwirtschaftssystemen im E-Commerce-Bereich, wie auch bei Online-Zeitungen ist diese Eigenschaft unabdinglich. Man könnte dies auch auf einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] nachbilden, indem man ununterbrochen einen Export der neuen und/oder aktualisierten Inhalte durchführt. Da dies jedoch die Performance des [[Publishing-/Staging-Server|Publishing-Servers]] dauerhaft reduziert und beispielsweise bei der Suche auch der Index immerzu aktualisiert bzw. neu erzeugt werden muss, kann dies nicht als angebrachter Workaround gewertet werden.<br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Indexierung von dynamischen Inhalten bei Google]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12016 2008-07-08T08:47:22Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]] kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein [[Live-Server|Live-Server]] hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Skalierbarkeit=<br /> Die Skalierbarkeit des Systems bezieht sich auf die Frage, wie einfach sich das System erweitern lässt, falls eine Überlast auftritt. Bei einem [[Live-Server|Live-Server]] muss bei Überlast das gesamte System erweitert werden. Wohingegen bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durch die klare Strukturierung einzelne Komponenten gezielt ausgebaut bzw. angepasst werden können.<br /> <br /> =Performance=<br /> Unter Performance versteht man die Reaktionszeit des Servers auf Anfrage der Benutzer und Redakteure des Systems. Die Antwortzeiten sind dabei abhängig von der Prozessorleistung, des Taktfrequenz und Größe des Hauptspeichers, der Zugriffzeiten auf Datenbanken und/oder des Dateisystems, der Durchsatzleistung, der Netzwerkanbindung uvm. Im Falle eines [[Publishing-/Staging-Server|Publishing-/Staging-Server]] kann die Hardware entsprechend den Anforderungen gezielt optimiert werden. Es wäre beispielsweise denkbar, auf Seiten des [[Publishing-/Staging-Server|Staging-Servers]] eine hoch performante Festplatte mit erweitertem Cache einzusetzen, um eine schnellen Zugriff auf die statischen Inhalte im Dateisystem zu gewährleisten, und der [[Publishing-/Staging-Server|Publishing-Server]] erhält einen vergleichsweise schnellen Prozessor für einen raschen Export der Inhalte. Im Gegensatz dazu sind bei einem [[Live-Server|Live-Server]] auch die Redakteure bei hohen Aufkommen von Benutzeranfragen von einer schlechten Reaktionszeit des Systems betroffen. Hier muss dann das gesamte System erweitert werden. <br /> <br /> =Ausfallsicherheit=<br /> Durch eine Trennung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]], kann auch die Ausfallsicherheit erhöht werden, da im Falle eines Defektes seitens des [[Publishing-/Staging-Server|Publishing-Servers]], der [[Publishing-/Staging-Server|Staging-Server]] immer noch erreichbar ist. Sollte der Staging-Server ausfallen, können einerseits die Redakteure davon unbeirrt weiterarbeiten und andererseits kann man die Inhalte schnell und einfach auf ein anderes System exportieren. Wenn jedoch ein [[Live-Server|Live-Server]] ausfällt, ist das System für keine Nutzergruppe erreichbar und es muss zuerst der Fehler analysiert, gefunden und behoben werden, was meist geraume Zeit in Anspruch nimmt.<br /> <br /> =Wartung=<br /> Auch bei der Wartung des Systems ist bei einem [[Live-Server|Live-Server]] die Webseite sowohl für die Benutzer, als auch die Redakteure nicht mehr erreichbar, wie es immer wieder bei [http://www2.ebay.com/aw/marketing-de.shtml ebay.de] freitags der Fall ist. Im Vergleich dazu ist der Ablauf bei einem [[Publishing-/Staging-Server|Publishing-/Staging-Server]] durchaus moderat. Wenn der [[Publishing-/Staging-Server|Staging-Server]] gewartet wird, so kann auch hier auf gesonderte Hardware exportiert werden, welche den zeitlich begrenzten „Ausfall“ überbrückt. Wartungsarbeiten am [[Publishing-/Staging-Server|Publishing-Server]] können meist nachts, wenn die Redakteure keine Inhalte bearbeiten, durchgeführt werden.<br /> <br /> =Suchmaschinen=<br /> Suchmaschinen wie Google und Yahoo! erfassen dynamische Inhalte nur begrenzt. Im Falle von Google werden datenbankgenerierte Web-Inhalte laut [http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Google-Hilfe] indexiert, es wird jedoch darauf hingewiesen, das der Crawler dabei Probleme hat und die Seiten dann ignoriert werden. Somit hat das [[Publishing-/Staging-Server|Publishing-/Staging-Server-System]], bei dem alle Seiten statisch hinterlegt sind, hier einen klaren Vorteil gegenüber dem [[Live-Server|Live-Server]], welcher sämtlichen Inhalt dynamisch erzeugt. Dieser Nachteil kann jedoch durch entsprechende Workarounds, wie sie [http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm XIST4C] nutzt, umgangen werden. Dabei wird die Seite nicht mit dynamischen Parametern in der URL angesprochen, sondern die URL enthält die eindeutige ID, anhand welcher die Seite im System gefunden wird. Daneben werden die XIST4C-Seiten mit der Dateiendung .htm versehen, um für die Suchmaschinen den Anschein zu erwecken, dass die Inhalte statisch sind.<br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.google.com/support/webmasters/bin/answer.py?answer=34431&amp;topic=8522 Indexierung von dynamischen Inhalten bei Google]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Vergleich_LiveServer_%E2%80%93_Publishing-/Staging-Server&diff=12012 2008-07-08T08:31:03Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Durch die Aufteilung in [[Publishing-/Staging-Server|Publishing-/Staging-Server]] ergeben sich zahlreiche Möglichkeiten, wie auch etliche Problematiken. Ein Vorteil auf Seiten des [[Live-Server|Live-Servers]], ist jedoch nicht automatisch ein Nachteil bei einem Publishing-/Staging-Server-System ist. Oftmals lassen sich die vermeintlichen Nachteile durch entsprechende Workarounds schnell und einfach beheben. <br /> <br /> =Sicherheit=<br /> Eines der treffendsten Argumente für die Trennung der Systeme ist die damit verbundene Erhöhung der Sicherheit. Bei einem Publishing-/Staging-Server-System kann der Publishing-Server durch die Separierung bereits auf Netzwerkebene getrennt werden. Es wäre hierbei denkbar den Publishing-Server hinter einer eigenen Firewall aufzustellen und/oder diesen nur über das Intranet erreichbar zu machen. Dadurch wird die Gefahr eines Angriffs von außen (also aus dem Internet) drastisch reduziert. Ein Live-Server hingegen kann diese Aufteilung aufgrund der Systemarchitektur nicht leisten.<br /> <br /> =Quellen=<br /> *[[Krüger, Jörg; Kopp, Matthias (2002): Web Content managen | Krüger, Jörg; Kopp, Matthias (2002): Web Content managen]]<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[http://www2.ebay.com/aw/marketing-de.shtml Ebay-System-News]<br /> *[http://www.xist4c.de/xist4c/web/suchmaschinenfreundlich_id_1028_.htm Suchmaschinenfreundliches Content Management System XIST4C]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=12008 2008-07-08T08:22:08Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[[Joomla!|Joomla!]]<br /> *[http://www.xist4c.de/ XIST4C]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=12007 2008-07-08T08:21:45Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[http://www.infopark.de/ Infopark CMS Fiona]<br /> *[http://www.reddot.de/ RedDot]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Live-Server-Architektur|Live-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management-System]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11994 2008-07-07T20:26:44Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[http://www.infopark.de/ Infopark CMS Fiona]<br /> *[http://www.reddot.de/ RedDot]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> [[Live-Server-Architektur|Live-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11993 2008-07-07T20:26:42Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =CMS-Beispiele=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[[Joomla!|Joomla!]]<br /> *[http://www.xist4c.de/ XIST4C]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11992 2008-07-07T20:25:43Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =CMS=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[http://www.infopark.de/ Infopark CMS Fiona]<br /> *[http://www.reddot.de/ RedDot]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> [[Live-Server-Architektur|Live-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11991 2008-07-07T20:25:27Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =CMS=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[[Joomla!|Joomla!]]<br /> *[http://www.xist4c.de/ XIST4C]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11990 2008-07-07T20:22:08Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =CMS=<br /> Content-Management-Systeme, die diese Architektur verwenden:<br /> *[[Joomla!|Joomla!]]<br /> *[http://www.xist4c.de/ XIST4C (offizielle Webseite)]<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> *[[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11989 2008-07-07T20:08:08Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> [[Publishing-/Staging-Server-Architektur|Publishing-/Staging-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server&diff=11988 2008-07-07T20:06:51Z

<p>Lichten: hat Publishing-/Staging-Server nach Publishing-/Staging-Server-Architektur verschoben: treffenderer Titel</p> <hr /> <div>#REDIRECT [[Publishing-/Staging-Server-Architektur]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11987 2008-07-07T20:06:51Z

<p>Lichten: hat Publishing-/Staging-Server nach Publishing-/Staging-Server-Architektur verschoben: treffenderer Titel</p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> [[Live-Server-Architektur|Live-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11986 2008-07-07T20:06:14Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Publishing Staging Server.gif|thumb|601px|Publishing-/Staging-Server-Architektur]]<br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> =Siehe auch=<br /> [[Live-Server-Architektur|Live-Server-Architektur]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11985 2008-07-07T19:58:53Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> <br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> [[Medium:Publishing Staging Server.gif|center]]<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11984 2008-07-07T19:53:19Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> <br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> [[Medium:Publishing_Staging_Server.gif‎|Publishing-/Staging-Server-Architektur]]<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Datei:Publishing_Staging_Server.gif&diff=11983 2008-07-07T19:45:17Z

<p>Lichten: In Anlehnung an die Bücher Web Content Management und Content Management in der Praxis</p> <hr /> <div>In Anlehnung an die Bücher [[Zschau, Oliver et. al. (2001): Web Content Management | Web Content Management]] und [[Christ, O. (2003): Content Management in der Praxis | Content Management in der Praxis]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11982 2008-07-07T19:43:53Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Publishing-/Staging-Server-Architektur&diff=11981 2008-07-07T19:43:22Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> <br /> Das Konzept des Publishing-/Staging-Server geht hierbei noch einen Schritt weiter. Die zugrundeliegende Systemarchitektur stellt für jede Teilnehmergruppe ein separates System zu Verfügung. Dadurch erhält man eine klare Trennung von redaktionellen und öffentlichen Inhalten. Die Redakteure arbeiten auf einem eigenen Publishing-Server, welcher die Inhalte in einer Datenbank speichert. Ihnen steht somit die gesamte Funktionalität eines Content Management Systems zur Verfügung.<br /> <br /> Die zu veröffentlichen Informationen werden zu vordefinierten Zeitpunkten aus dem System exportiert. Die Aufbereitung der Informationen, also Inhalte aus der Datenbank holen und mit den entsprechenden Templates verknüpfen, erfolgt zum Zeitpunkt des Exports. Diese werden anschließend als statisches HTML auf dem separierten Staging-Server abgelegt. Durch diesen Export-Mechanismus werden die Informationen jedoch erst zeitlich verzögert publiziert.<br /> <br /> Für die Benutzer des Internetauftrittes steht ein eigenes Systems zur Verfügung, der Staging-Server. Hier werden nur statische Inhalte hinterlegt, auf welchem ein einfacher Web-Server, wie z.B. der dateibasierte Apache-HTTP-Server auf Anfrage der Benutzer lediglich statische Internetseiten zurückgibt. <br /> <br /> Durch das Aufspalten der Logik ist es nun möglich, die einzelnen Systeme auch auf Netzwerkebene zu trennen. <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server&diff=11980 2008-07-07T19:33:54Z

<p>Lichten: hat Live-Server nach Live-Server-Architektur verschoben: treffenderer Titel</p> <hr /> <div>#REDIRECT [[Live-Server-Architektur]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11979 2008-07-07T19:33:54Z

<p>Lichten: hat Live-Server nach Live-Server-Architektur verschoben: treffenderer Titel</p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]<br /> <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11978 2008-07-07T14:22:08Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teilnehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]<br /> <br /> <br /> =Quellen=<br /> *[[Zschau, Oliver et. al. (2001): Web Content Management | Zschau, Oliver et. al. (2001): Web Content Management]]<br /> *[[Christ, O. (2003): Content Management in der Praxis | Christ, O. (2003): Content Management in der Praxis]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Datei:Live-Server.gif&diff=11977 2008-07-07T14:17:00Z

<p>Lichten: </p> <hr /> <div>In Anlehnung an die Bücher [[Zschau, Oliver et. al. (2001): Web Content Management | Web Content Management]] und [[Christ, O. (2003): Content Management in der Praxis | Content Management in der Praxis]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11976 2008-07-07T14:02:29Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> <br /> [[Medium:Live-Server.gif|thumb|340px|Live-Server-Architektur]]<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teil-nehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Datei:Live-Server.gif&diff=11975 2008-07-07T13:57:33Z

<p>Lichten: </p> <hr /> <div></div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Datei:Live_server.gif&diff=11974 2008-07-07T13:54:28Z

<p>Lichten: in Anlehnung an das Buch Content Management in der Praxis</p> <hr /> <div>in Anlehnung an das Buch [[Christ, O. (2003): Content Management in der Praxis | Content Management in der Praxis]]</div>

Lichten https://glossar.hs-augsburg.de/w/index.php?title=Live-Server-Architektur&diff=11973 2008-07-07T13:31:12Z

<p>Lichten: </p> <hr /> <div>=Definition=<br /> Die Architektur eines Live-Servers hat viel mit dem Aufbau von herkömmlichen Websites gemeinsam. Das System ist eine geschlossene Anwendung die von Benutzern (Teilnehmer, die auf veröffentlichte Inhalte zugreifen), als auch Redakteuren (Teil-nehmern, die Inhalte einpflegen) gleichermaßen über einen zentralen Server genutzt wird. <br /> Die Inhalte werden anhand eines Aufrufs über einen Webbrowser angefordert. Dabei wird auf dem Server ein Prozess gestartet, welcher die Inhalte aus einer Datenbank holt und anschließend diese mit dem entsprechenden Template verknüpft. Das daraus generierte HTML-Dokument wird an den Aufrufer zurückgegeben. <br /> Somit wird abhängig von den Anfrageparametern erst dynamisch das eigentliche HTML-Dokument generiert. Es gibt also bei dieser Art des Web-Publishings keine statischen Inhalte.<br /> <br /> [[Kategorie:Content-Management]]<br /> [[Kategorie:Glossar]]</div>

Lichten