UX-Bridge - Whitepaper

e-Spirit AG

FirstSpirit Version 5.x

17.01.2017
Inhaltsverzeichnis

1. Einführung und Vision

1.1. Websites und User Experience

Die Anforderungen an moderne Webauftritte sind in den letzten Jahren rasant gestiegen. Diese Dynamik bezieht sich neben der Optimierung der redaktionellen Prozesse zunehmend auf die Funktionalitäten des Webauftritts, welcher immer mehr als interaktives Kommunikationsmedium mit Kunden oder Interessenten wahrgenommen wird.

Die Bedürfnisse bzgl. der Steuerung dieser Kundenkommunikation werden zunehmend anspruchsvoller, weil die Erwartungshaltung auf Seiten des Konsumenten auf einem sehr hohen Niveau liegt. Der anspruchsvolle Kunde erwartet eine hervorragende User Experience, wobei dieser Begriff eine Vielzahl von Aspekten wie gute Usability, zielgruppenspezifische Ansprache sowie die Auslieferung von Informationen zum richtigen Zeitpunkt in der richtigen Granularität umfasst. Auch die Performance einer Website bekommt einen immer höheren Stellenwert, sowohl bei der Benutzerakzeptanz als auch bei Aspekten wie dem Suchmaschinen-Ranking.

1.2. Hybrid-Architektur

Um den steigenden Anforderungen gerecht zu werden, ist eine adäquate technische Lösung auf Seiten des Content Management Systems (CMS) notwendig. Das breite Spektrum der User Experience-Anforderungen macht eine ungewöhnlich flexible Architektur des CMS unerlässlich. Dies gilt besonders für Aspekte, die klassische gegensätzliche Ziele darstellen, wie z. B.

  • Hohe Dynamik der Inhalte versus performante Auslieferung der Website
  • Stabile Systemarchitektur versus Integration von vielen verschiedenen Werkzeugen

Um trotz dieser Trade-Offs eine für den jeweiligen Kunden optimale Lösung bieten zu können, stellt FirstSpirit eine besonders anpassbare Architektur zur Verfügung, die sogenannte Hybride Architektur.

Die hybride Architektur FirstSpirits macht es gerade in integrationslastigen Szenarien sehr leicht, eine passgenaue Lösung zu etablieren, die den spezifischen Eigenschaften und Anforderungen des konkreten Webauftritts Rechnung trägt. Eine "One-Size-Fits-All"-Architektur funktioniert erfahrungsgemäß nur in sehr simplen Anwendungsfällen. Mit zunehmender Anzahl und Komplexität von Webauftritten steigt jedoch die Vielfalt der zu integrierenden Drittsysteme. Gerade in größeren Unternehmen ist dies ein häufig anzutreffendes Merkmal, da neben der CMS-Komponente noch weitere Systeme wie E-Commerce-Shops, Enterprise Portale aber auch selbst entwickelte Webanwendungen vorgegeben und einzubinden sind. In solchen Fällen lässt sich durch die Hybrid-Architektur FirstSpirits eine feine und vor allen Dingen projektindividuelle Abstimmung zwischen Performance, Stabilität, und Wartbarkeit realisieren.

FirstSpirit folgt mit seiner hybriden Architektur der Regel:

So viel Dynamik wie nötig, so viel Inhalte vorgenerieren wie möglich.

Unter einem hybriden CMS verstehen wir somit ein Content Management System, welches jedem Kunden die Wahlfreiheit lässt, welche Elemente einer Website voll dynamisch und welche Elemente bereits fertig vorgeneriert ausgeliefert werden.

Technisch bedeuten die beiden Varianten:

  • Voll-dynamisch: Die redaktionellen Inhalte werden zum Zeitpunkt des Benutzerzugriffs auf eine Webseite (Request-Zeitpunkt) live aus einem oder mehreren Content-Repositories ausgelesen und zusammengestellt.
  • Vorgeneriert: Die redaktionellen Inhalte sind bereits physikalisch in einer Webseite (z. B. einer HTML-Datei) enthalten und können direkt an den User ausgeliefert werden.

Eine Besonderheit des Hybrid-Ansatzes FirstSpirits liegt darin, dass die Entscheidung für die eine oder andere Variante sehr feingranular für jedes Element einer einzelnen Seite festgelegt werden kann. Konkrete Beispiele für diese Art der Architektur werden im Kapitel Beispiele für Einsatzszenarien erläutert.

1.3. UX-Bridge: Connecting Content and User Experience

Mit dem Trend zu immer interaktiveren Websites kommt dem Thema „dynamischer Zugriff auf redaktionelle Inhalte“ eine stetig steigende Bedeutung zu. Immer dort, wo eine Vorgenerierung von Inhalten nicht möglich ist, muss dynamisch auf die CMS-Inhalte zugegriffen werden. Dynamisch bedeutet hier, dass sich der Inhalt potentiell für jeden Website-User und zu jedem Zeitpunkt ändern kann. Jede Information, die länger als 1-2 Minuten auf der Website steht und für alle Benutzer identisch ist (z. B. ein Artikel bei einem News-Portal), gilt hier nicht als dynamisch, sondern als potentiell vorgenerierbar. Nichtsdestotrotz nehmen die dynamischen Szenarien zu, da eine personalisierte Content-Auslieferung einen wichtigen Beitrag zur User Experience liefern kann.

FirstSpirit bietet mit dem UX-Bridge-Modul eine Infrastruktur für die Anforderung einer dynamischen Content-Delivery-Plattform. Somit ergänzt das Modul den hybriden Ansatz um eine Standardinfrastruktur für dynamische Content-Auslieferung. Als Faustformel für die beiden hybriden Architekturvarianten lässt sich festhalten:

  • Vorgenerierte Content-Auslieferung eines redaktionellen Inhaltes:
    → FirstSpirit Standard Deployment
  • Voll dynamische Content-Auslieferung eines redaktionellen Inhaltes:
    → UX-Bridge

Wichtig ist zu beachten, dass diese Entscheidung nicht global für den ganzen Webauftritt, sondern jeweils einzeln für jede Art von Content-Element getroffen werden kann (siehe auch Kapitel Beispiele für Einsatzszenarien).

Beim Einsatz der UX-Bridge ist somit pro Projekt und pro (feingranularen) Anwendungsfall zu entscheiden, ob die Dynamisierung fachlich und technisch notwendig bzw. sinnvoll ist (siehe oben: Trade-Off Dynamik versus Performance). Auf Basis dieser Entscheidung lassen sich dann sehr leicht intelligente und Anwendungsfall-optimierte Lösungen realisieren.

1.4. Kundenbindung durch Interaktion

Um eine echte Interaktion mit den Benutzern einer Website zu ermöglichen, reicht eine reine Content-Auslieferung, selbst wenn sie personalisiert und kontextbezogen erfolgt, nicht aus. Vielmehr existiert eine Vielzahl von Anwendungsfällen, in denen Informationen von der Website zurück Richtung Content-Erstellung/CMS fließen müssen. Beispiele für Anwendungsfälle eines solchen Rückkanals sind User-generated Content (UGC) oder auch statistische Daten bzgl. des Benutzerverhaltens, die in einem zweiten Schritt wieder zur Optimierung der Content-Auslieferung verwendet werden können.

Mit Hilfe der UX-Bridge können zum einen UGC-Inhalte über einen Standardweg abgelegt und wieder ausgelesen werden. Gleichzeitig lässt sie sich nutzen, um bestimmte Informationen von der Website (z. B. wie viele Kommentare hat mein Artikel schon bekommen) direkt ins Redaktionssystem zurückfließen zu lassen, um sie dort passend weiter zu verarbeiten, z. B. für Ranking-Listen.

1.5. Mobile First

Die Verwendung von mobilen Endgeräten zur Darstellung von (Web-)Content nimmt seit einigen Jahren exponentiell zu. Neben der "normalen" Website ist es inzwischen fast schon eine Standardanforderung, auch einen mobilen Ausgabekanal für Smartphones oder Table-PCs zu unterstützen. Der "Mobile First"-Ansatz geht sogar noch einen Schritt weiter und empfiehlt die mobile Variante einer Website noch vor der konventionellen Variante zu entwickeln. Die Gründe liegen darin, dass man sich im mobilen Kanal deutlich mehr auf die wesentlichen Punkte, d.h. den für den Kunden „relevanten“ Content, beschränken bzw. fokussieren muss. Weiterhin gibt es auf mobilen Geräten neben einigen technischen Einschränkungen (z. B. Bildschirmgröße) auch erweiterte Eigenschaften, wie z. B. Standorterfassung per GPS, Gestensteuerung, wechselnde Seitenverhältnisse bei Hoch- und Querformat oder eine Offline-Fähigkeit. Diese müssen schon bei der initialen Konzeption einer Website mit berücksichtigt werden, da sie ohne eine komplette Neukonzeption nur schwer nachträglich hinzufügen sind.

Durch die strikte Trennung von Inhalt und Layout erlaubt FirstSpirit sehr leicht eine Erzeugung von Mobile-konformen Inhaltsfragmenten, z. B. als XML oder HTML-Fragment.

Die UX-Bridge ergänzt diesen Ansatz um eine flexible Content-Delivery-Infrastruktur, die die Anforderungen an mobil darzustellenden Content optimal unterstützt. Ein konkretes Beispielszenario ist im Kapitel Mobiles Newsportal beschrieben.

1.6. Neue Anforderungen: Big Data, NoSQL, Realtime Analytics

Moderne Webauftritte stellen immer höhere Anforderungen an die zugrundeliegende technische Infrastruktur.

Die zu verwaltenden Datenmengen nehmen sprunghaft zu, weil neben den klassischen redaktionellen Inhalten auch zunehmend User-generated Content (UGC) sowie statistische Daten aus dem Verhalten der Website-Benutzer verwaltet und ausgewertet werden müssen. Die Speicherung und Verwaltung solch großer Datenmengen wird auch mit dem Begriff Big Data assoziiert.

Mit der steigenden Menge von Daten geht gleichzeitig auch eine Diversifizierung der Datentypen einher. Stark redaktionelle getriebene Webseiten bestehen häufig aus unstrukturierten Daten, während Website-Daten aus Backendsystemen (z. B. Produktinformationen) eher stark strukturiert sind. User-generated Content, wie Kommentare oder Bewertungen, sind meist sehr einfach und flach strukturiert. Eine weitere Art von Benutzerdaten spiegeln Abhängigkeiten oder Beziehungen wider (wer hat sich was angesehen, wer kennt wen, etc.). Gerade in Online-Communities ist dieser Social-Graph eine wichtige Informationsquelle für Benutzerinteraktionen. Ein weiterer Anwendungsfall für Beziehungen zwischen Content-Elementen ist das sogenannte Semantische Web. Dort werden durch die explizite Modellierung von Verbindungen die Inhalte zueinander in Relation gesetzt, z. B. für bessere Suchmöglichkeiten.
Aus diesem Grund werden in Zukunft neue Arten von Datenablagen eine immer größere Rolle spielen, z. B. NoSQL oder Graphdatenbanken.

Neben der Speicherung von redaktionellen und benutzerbezogenen Daten kommt der Auswertung dieser Daten ein immer höherer Stellenwert zu. Bei der Datenanalyse geht der Trend zunehmend in Richtung Realtime-Reporting. Häufig werden auch Methoden aus dem Datawarehousing und der Business Intelligence verwendet, um zu relevanten Analyse zu kommen.

Beim Entwurf einer zukunftsfähigen Architektur für eine Website sind die erwähnten Randbedingungen zu berücksichtigen:

  • Ständig steigenden Datenmenge
  • Verwaltung sehr unterschiedlicher Datentypen
  • Steigende Anforderungen bei der Auswertung von Daten (Reporting)

Bemerkenswert ist, dass die klassischen Content Management Repositories für diese umfangreichen Anforderungen überhaupt nicht entworfen wurden. Aus den Trade-Offs der Anforderungen lässt sich ableiten, dass ein "One-Size-Fits-All"-Ansatz für die Persistenz der Daten auf Dauer nicht tragfähig ist (siehe Kapitel Hybrid-Architektur).

Die FirstSpirit UX-Bridge folgt daher einem neuen Ansatz: Ihre Architektur erlaubt eine flexible Auswahl der Datenablage (Persistenz) für den dynamischen Zugriff, abhängig von den fachlichen und technischen Anforderungen (siehe Kapitel Polyglot Persistence).

1.7. Cloud-Ready Solution

Die UX-Bridge wurde von Anfang an so entworfen, dass ein Einsatz der Komponente in der Cloud problemlos möglich ist.

Gerade Aspekte wie

  • Skalierung und Performance
  • Ausfallsicherheit/Failover
  • Betriebskosten und Total-Cost-Of-Ownership (TCO)

sind gute Indikatoren für den Betrieb der UX-Bridge in einer Cloud-Infrastruktur, wie z. B. Amazon. Gleiches gilt analog für den Betrieb der kompletten Website und natürlich auch für das FirstSpirit-Redaktionssystem. Wie bei allen Architekturvarianten ist auch dies eine optionale Möglichkeit, die in der jeweiligen Kunden- und Projektsituation auf Eignung geprüft werden muss.

1.8. Content-Integration-Plattform

Neben der dynamischen Auslieferung von redaktionellen Inhalten in Richtung Website ist die Über- bzw. Weitergabe von Content in Richtung Drittapplikationen ein wichtiges Einsatzszenario für die UX-Bridge.

Beispiele für diesen Anwendungsfall sind:

  • Übergabe von Content an selbst entwickelte Webanwendungen (z. B. Produktkonfigurator oder Filialsuche)
  • Übergabe von Content an Cloud/SaaS-Anwendungen, die in die Website mit eingebunden werden sollen und auf/mit redaktionellen Inhalten arbeiten (z. B. externe Recommendation-Engine oder eine Suchmaschine)

Während das FirstSpirit-Redaktionssystem als Content-Integration-Plattform für die Backend-Seite fungiert, nimmt die UX-Bridge diese Rolle auf der Live-Website ein.

2. Architekturbeschreibung

Die UX-Bridge stellt eine Erweiterung der klassischen vorgenerierenden FirstSpirit-Architektur dar. In Abgrenzung zu einem "Volldynamischen CMS" wird bei FirstSpirit davon ausgegangen, dass der Content im Redaktionssystem (Backend) zusammengestellt und im Rahmen einer sogenannten Generierung (häufig) auch schon mit dem passenden Ziellayout versehen wird. Das Ergebnis sind dann z. B. fertige HTML-Seiten. Anschließend erfolgt ein Übertragen (Deployment) der erzeugten Dateien Richtung Livesystem, z. B. ein Web- oder Application-Server. FirstSpirit dient somit als Content-Integration-Layer für redaktionellen Inhalte und unterschiedliche angebundene Backendsysteme (siehe Abbildung FirstSpirit-Architektur).

FirstSpirit-Architektur
Abbildung 1. FirstSpirit-Architektur


2.1. Architekturübersicht UX-Bridge

Im Rahmen der Hybrid-Architektur ergänzt die UX-Bridge FirstSpirit um eine dynamische Content-Auslieferung mit Standardmittel. Andere (UX-Bridge freie) Alternativen zur dynamischen Content-Auslieferung sind übrigens ausdrücklich möglich. Jedoch sollte zunächst geprüft werden, ob ein standardnaher Ansatz wie die UX-Bridge nicht mehr Vorteile bietet.

In der UX-Bridge-Architektur werden diejenigen Content-Elemente, die dynamisch über eine Webapplikation ausgelesen werden sollen, nicht wie üblich als fertige (HTML-)Dateien auf den Webserver gelegt. Stattdessen gibt es ein sogenanntes Live-Repository, welches die relevanten Daten von FirstSpirit aufnimmt und an die dynamischen Webapplikationen weitergibt (siehe Abbildung Vorgenerierung in Kombination mit der UX-Bridge).

Vorgenerierung in Kombination mit der UX-Bridge
Abbildung 2. Vorgenerierung in Kombination mit der UX-Bridge


Wichtig ist hierbei, dass die beiden Ansätze Vorgenerierung (linke Seite der Grafik) und Live-Repository (rechte Seite der Grafik) in der Regel kombiniert eingesetzt werden (siehe Abbildung Vorgenerierung und Dynamik).

So kann in einem News-Portal z. B. die normale Pressemitteilung komplett statisch vorgeneriert werden (als fertiges HTML-Fragment), während auf derselben Seite ein Top-Rating-Widget in der Marginalspalte dynamisch die Überschrift derjenigen Pressemitteilungen „live“ anzeigt, die am besten bewertet worden sind (in der Abbildung blau umrandet).

Die hybride Architektur FirstSpirits erlaubt eine beliebige Mischung solcher vorgenerierten und komplett dynamischen Inhalte.

Vorgenerierung und Dynamik
Abbildung 3. Vorgenerierung und Dynamik


2.1.1. Inhalte aktualisieren

Wenn wir bei dem zuvor beschriebenen News-Szenario bleiben, so erfolgt eine Aktualisierung der Website über folgende Schritte:

  1. Ein Redakteur schreibt eine neue Pressemitteilung, die anschließend per Workflow freigegeben wird.
  2. Der letzte Workflow-Schritt besteht aus der Veröffentlichung der Pressemitteilung, die sich wieder aufteilen lässt:

    1. Die Pressemitteilungsdetailseite wird komplett vorgeneriert (als statisches HTML) und anschließend auf den Webserver übertragen. Gleiches gilt für die News-Übersichtsseite, auf der die neue Mitteilung als erste Meldung erscheinen soll.
    2. Die für die dynamische Anzeige relevanten Daten der Pressemitteilung (hier Überschrift der News) werden von FirstSpirit erzeugt und direkt (ohne die Erzeugung einer Datei) in das Live-Repository überführt. Das Format der Daten ist beliebig, wobei die Referenzimplementierung XML verwendet, welches HTML-Fragmente enthalten kann.

2.1.2. Inhalte ausgeben

Nach der Content-Aktualisierung ruft ein Website-Benutzer die Presseübersichtsseite auf, welche die neuste Meldung als ersten Link enthält. Ein Klick auf diesen Link öffnet die gerade aktualisierte Detailseite (siehe Abbildung Vorgenerierung und Dynamik). Rechts in der Marginalspalte der Seite ist eine dynamische WebApp, die zum Request-Zeitpunkt Kontakt zum Live-Repository aufnimmt und die Top-News ausliest und anzeigt.

Mit welchen technischen Mechanismen (z. B. über welches Webframework) die WebApp ihre Inhalte aus dem Live-Repository ausliest, ist von der Architektur nicht vorgegeben. Hier können beliebige passende Frameworks und Protokolle verwendet werden.

2.1.3. UX-Bridge Architektur im Detail

Nachdem der grobe Mechanismus zum Content-Update mit der UX-Bridge erläutert wurde, werden in diesem Kapitel die technischen Details des Moduls näher beschrieben (siehe Abbildung UX-Bridge im Detail).

Auf der Live-Seite (dem Presentation-Layer) besteht die UX-Bridge aus drei Komponenten:

UX-Bus (oder auch Content-Bus)

Der UX-Bus bildet die zentrale Infrastrukturkomponente um Inhalte von FirstSpirit in ein oder mehrere Live-Repositories zu verteilen. Technisch basiert die Referenzimplementierung des UX-Bus auf ActiveMQ (siehe http://activemq.apache.org/). Gleichzeitig kann der UX-Bus auch genutzt werden, um Drittsysteme mit relevantem FirstSpirit-Content zu versorgen (z. B. einen Suchindex oder eine Recommendation-Engine). Dritter Einsatzzweck des UX-Busses ist der Aufbau eines Rückkanals von der Website Richtung FirstSpirit-Backend (siehe auch Kapitel Kundenbindung durch Interaktion).

Der UX-Bus bildet somit die zentrale Integrationskomponente auf der Live-Website (siehe Kapitel Content-Integration-Plattform), über die FirstSpirit mit den Repositories und WebApps interagieren kann, aber ggf. auch die WebApps untereinander. Mit Hilfe des UX-Busses können somit sämtliche beteiligten Komponenten Daten und Events austauschen.

Technisch basiert der UX-Bus auf einer Message Oriented Middleware (MOM). Somit sind die Komponenten der UX-Bridge nur lose miteinander gekoppelt. Gleichzeitig ist durch eine asynchrone Kommunikation und den Einsatz von Warteschlangen die Skalierbarkeit gewährleistet. Die Referenzimplementierung des UX-Busses verwendet dafür ActiveMQ (siehe http://activemq.apache.org) als Message Broker und Apache Camel (http://camel.apache.org/) für das Routing und die Konvertierung der Nachrichten.

UX-Bridge im Detail
Abbildung 4. UX-Bridge im Detail


Live-Repository

Das Live-Repository ist eine Datenhaltungskomponente, die von FirstSpirit gefüllt und von Webapplikationen ausgelesen wird. Wichtiges Architekturparadigma der UX-Bridge ist hier: Die Art und Anzahl der Repositories wird nicht vorgegeben, weil je nach Aufgabenart unterschiedliche Repositories unterschiedlich gut geeignet sind (siehe Kapitel Polyglot Persistence).

In vielen Fälle kann es auch sinnvoll sein, das Live-Repository nicht ausschließlich von FirstSpirit aus zu befüllen, sondern auch von der Website aus. Dies ist z. B. bei der Verwaltung von User-generated Content (UGC) relevant. Im Live-Repository wird dann FirstSpirit-Content (z. B. Pressemitteilungen) mit UGC verknüpft (z. B. Bewertung der Pressemitteilungen).

Repository-Adapter
Der Repository-Adapter übernimmt das Einfügen der FirstSpirit-Inhalte in das Content-Repository. Gleichzeitig erfolgt hier auch das Mapping des projektspezifischen FirstSpirit-Datenmodells eines Content-Objektes (z. B. ein XML-Konstrukt mit der Pressemitteilung) auf das Datenmodell im Repository, welches meist von der Webapplikation bestimmt wird (z. B. eine relationale oder NoSQL-Datenbank). Damit hat der Repository-Adapter immer einen projektspezifischen Anteil, d.h. für jede Art von Daten ist eine passende Mapping-Logik zu implementieren.
Wahl des Live-Repositories

Die Auswahl der „richtigen“ Live-Repositories ist eine wichtige Architekturentscheidung innerhalb des Projekts. In der Planungsphase eines Projekts sind immer zwei wichtige Fragen zu beantworten:

  1. Welche redaktionellen Daten sollen/müssen in ein Live-Repository überführt werden?
  2. Welche Art von Repository ist für diese Art von Daten und (Web-)Anwendung optimal?

Generell macht die UX-Bridge hier keine festen Vorgaben, da im Sinne einer aufgabenangemessenen Auslieferungsinfrastruktur verschiedene Kriterien berücksichtigt werden müssen:

Art der Webapplikation und Daten
Welche Art von Webapplikation in Bezug auf die Datenpersistenz soll konkret verwendet werden? Wie sieht das Datenmodell der Anwendung aus und in welcher Art von Persistenz lässt sich dieses Datenmodell optimal abbilden? Ist ein statisches Datenmodell passend oder ist eine dynamische Erweiterbarkeit notwendig? Ist z. B. Transaktionalität wichtig oder liegt der Schwerpunkt auf der Verfügbarkeit?[1]
Performance- und Skalierungsanforderungen
Wie sind die Anforderungen Richtung Performance und Skalierbarkeit des Repositories? Ist eine horizontale Skalierbarkeit wichtig? Wie relevant ist das Abfedern von Lastspitzen? Wie elastisch muss die Performance angepasst werden können?
Drittsysteme
Welche weiteren Systeme müssen auf die Daten zugreifen können? Mit welcher Art von Persistenz kommen die Drittsysteme am besten zurecht?
Tool- und Framework-Support
Mit welcher Art von Repository kommt das eingesetzt Webframework besonders gut zu Recht? Wofür gibt es fertige Plugins? Gibt es weitere Tools (z. B. für Import/Export/Reporting), die auf das Repository zugreifen müssen?
Knowhow im Team
Mit welcher Art von Persistenz sind die Entwickler am besten vertraut? Mit welchem System ist die beste Entwicklungsperformance zu erwarten?

Dies sind alles Fragen, die vor der Auswahl eines Repositories gestellt und beantwortet werden sollten, um auf dieser Basis dann eine Entscheidung zu treffen.

Für einen ersten Überblick, sind hier einmal die üblichen Arten von Repositories aufgeführt:

  • Relationale Datenbank (Oracle, MySQL, PostgreSQL etc.)
  • NoSQL Datenbanken (MongoDB, Cassandra, Redis, SimpleDB, DynamoDB, etc.)
  • Index-basierte Speicher (Lucene, Solr, Elasticsearch, Sphinxsearch, etc.)
Polyglot Persistence

Bei der beschriebenen Auswahl eines passenden Repositories für konkrete Anwendungsfälle kann es durchaus vorkommen, dass (sogar innerhalb eines Projekts) mehrere unterschiedliche Repositories zum Einsatz kommen, um eine aufgabenangemessene Lösung zu realisieren. Dieser Architekturansatz wird auch Polyglot Persistence Strategie genannt. Hinter diesem Begriff steht der einfache Ansatz:

Wähle die passende Persistenz für den jeweiligen Anwendungsfall.

Der gleichzeitige Einsatz unterschiedlicher Persistenzarten für Daten ist dabei ausdrücklich erlaubt, wenn dies fachlich sinnvoll ist. Weitere Details zum Thema Polyglot Persistence sind hier zu finden: http://martinfowler.com/articles/nosql-intro.pdf

Die UX-Bridge folgt genau diesem Ansatz, da in jedem Kontext die fachlichen Anforderungen die Auswahl der konkreten Persistenzarten bestimmen (siehe auch Kapitel Mobile First).

2.2. Beispiele für Einsatzszenarien

Um die Frage zu beantworten, in welchen Szenarien die UX-Bridge sinnvoll eingesetzt werden kann, sind im Folgenden einige Praxisbeispiele aufgeführt. Zur Unterstützung tragfähiger Architekturentscheidungen wird in diesem Zusammenhang insbesondere betrachtet, welche Aspekte dynamisiert und welche sinnvollerweise vorgeneriert werden. Auch die Wahl eines passenden Repositories wird pro Anwendungsfall diskutiert.

2.2.1. News-Szenario inkl. User-generated Content (UGC)

Betrachten wir erneut das News-Szenario des Kapitels Architekturübersicht UX-Bridge. In einer Website gibt es eine Vielzahl von Nachrichten, die über die FirstSpirit-Datenquellen verwaltet werden. Auf der Website gibt es News-Übersichtsseiten (mit den aktuellsten 10 News auf der ersten Seite) sowie News-Detailseiten (siehe Abbildung News-Szenario). Auf den Detailseiten ist neben der Pressemitteilung (roter Rahmen) auch ein Top-News-Widget (blauer Rahmen), welches dynamisch die Top-News anhand bestimmter Kriterien (am besten bewertet, etc.) darstellt.