CoreMedia ist ein auf große Webseiten ausgerichtetes, Java-basiertes Content Management System, das sowohl für Unternehmenswebseiten wie telekom.com als auch für Nachrichtenseiten wie bild.de zum Einsatz kommt. Dieser Artikel beschreibt die Arbeit mit CoreMedia aus Entwicklersicht.
Systemarchitektur
Da CoreMedia für Webseiten mit großer Last ausgelegt ist, ist das System aus redundant ausgelegten, verteilten Komponenten aufgebaut. Das System, mit dem die Redakteure arbeiten ist von der Auslieferungsschicht getrennt, ein Publikationsprozess kopiert die Inhalte vom Redaktionssystem in das ausliefernde System.
Das Herz von CoreMedia ist der Content Server, der alle Inhalte in einer Datenbank speichert und zugreifbar macht. Man greift selten direkt auf den Content Server zu, die Arbeit erfolgt über andere Systeme, die mit dem Content Server kommunizieren. In der Vergangenheit haben Redakteure zur Arbeit einen Java-Client verwendet (früher Editor genannt, heute Site Manager), seit CoreMedia 7 gibt es mit dem Studio eine webbasierte Oberfläche, die zur Verwaltung und Bearbeitung von Inhalten verwendet werden kann. Eine Preview-Applikation zeigt den Redaktionsstand vor der Publikation an. Workflows, die im Workflow Server verwaltet werden, können die redaktionellen Prozesse unterstützen.
Das Live-System besteht aus mehreren, redundant ausgelegten Komponenten. Es gibt einen Master Live Server und optional noch mehrere Replication Live Server, die zur Lastverteilung und Ausfallsicherheit eingesetzt werden. Die Content Management Server werden von der Content Application Engine (CAE) angesprochen, die die Auslieferungslogik der Webseite enthält. Für die Suche und flexible Auslieferung von Inhalten kommen Instanzen von Apache Solr zum Einsatz, die durch den Feeder mit Inhalten versorgt werden.
Dokumentenmodell
Das Dokumentenmodell der Anwendung beschreibt die Content-Typen, die im System verfügbar sind. CoreMedia stellt mit der Blueprint-Applikation ein generisches Dokumentenmodell zur Verfügung, das als Basis für eigene Applikationen verwendet werden kann. Es ist jedoch auch möglich, alle Typen von Grund auf selbst zu entwickeln. Da das Dokumentenmodell die Speicherung des Inhalts beschreibt wird es quer durch die Komponenten im System eingesetzt.
Das Modell ist objektorientiert aufgebaut, mit Dokumenten, die aus Attributen bestehen. Es gibt 6 Attributtypen wie String (Text fester Länge), XML (Text mit variabler Länge) oder Blob (Binärdaten), die die Basis aller Dokumente bilden. Eine Konfiguration in XML beschreibt das Dokumentenmodell und kann für einen Artikel mit Titel, Text und verwandten Artikeln beispielsweise so aussehen:
<DocType Name=“Article“>
<StringProperty Name=“title“/>
<XmlProperty Grammar=“coremedia-richtext-1.0″ Name=“text“/>
<LinkListProperty LinkType=“Article“ Name=“related“/>
</DocType>
Content Application Engine
Der Großteil des Codes den man als Entwickler schreibt ist für die Auslieferung der Webseite über die Content Application Engine, entweder für den Preview- oder die Live-Server. Man entwickelt eine Standard-Java-Webanwendung, die aus mehreren Maven-Modulen zusammengebaut wird. Der CAE-Code basiert stark auf Spring MVC mit dem CoreMedia-spezifischen ViewDispatcher, der für die Darstellung der unterschiedlichen Dokumente zuständig ist. Das Dokumentenmodell wird über sogenannte Contentbeans zur Verfügung gestellt, die aus dem Dokumentenmodell generiert werden können. Contentbeans greifen bei Bedarf auf den Content in CoreMedia zu und können weitere Businesslogik enthalten. Es handelt sich also nicht um POJOs im klassischen Sinn sondern ähneln eher ActiveRecord-Instanzen in der Rails-Welt.
Unser Beispiel von oben würde über eine Contentbean mit Gettern für den Titel (java.lang.String), den Text (com.coremedia.xml.Markup) und eine java.util.List (typisiert auf de.fhopf.Article) abgebildet werden.
Die Ausgabe der Contentbeans passiert in JSPs, die nach einer bestimmten Logik nach Klassen oder Interfaces benannt sein müssen. Ein Objekt Article das im Package de.fhopf liegt, würde dann in de.fhopf/Article.jsp abgelegt werden. Falls eine bestimmte Darstellungslogik für List-Instanzen benötigt wird, würde diese in java.util/List.jsp abgelegt werden. Eine unterschiedliche Darstellung ist über View-Namen möglich. Ein Article, der als Link dargestellt werden soll, könnte dann in de.fhopf/Article.link.jsp abgelegt werden.
Das Auffinden der JSPs erfolgt über eine der in CoreMedia enthaltenen Spring-Komponenten, dem ViewDispatcher, einem <a href=“http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-viewresolver“>ViewResolver</a>, der den zu verwendenden View über den Inhalt des Models bestimmt. Die JSP, die aufgerufen wird, kann dann weitere Includes auf andere Elemente enthalten, seien es CoreMedia Contentbeans oder andere Attribute. Die Includes laufen dann wieder durch den ViewDispatcher, die zu verwendende JSP wird über den selben Mechanismus aufgelöst.
Zeit für ein Beispiel, die Darstellung der Liste der verwandten Artikel. Angenommen man ruft die CAE mit einer bestimmten Content-Id auf, die einen Artikel identifiziert. Der Standard-Mechanismus delegiert diesen Aufruf an die oben beschriebene Article.jsp. Diese könnte das folgende Fragment enthalten, um die verwandten Artikel darzustellen:
<cm:include self=“${self.related}“/>
Wir geben im Tag nicht an, welche JSP inkludiert werden soll. CoreMedia merkt automatisch, dass wir eine List-Instanz einbinden wollen, zum Beispiel eine java.util.ArrayList. Da es keine JSP unter java.util/ArrayList.jsp gibt, sucht CoreMedia automatisch nach implementierten Interfaces in der Klasse. In diesem Fall wird java.util/List.jsp gefunden, welche den folgenden Code enthalten könnte:
<ul>
<c:forEach items=“${self}“ var=“item“>
<li><cm:include self=“${item}“ view=“link“></li>
</c:forEach>
</ul>
Da die List-Instanz in unserem Fall Article-Implementierungen enthält wird für jeden Eintrag Article.link.jsp inkludiert, die dann den Link darstellt.
Der von CoreMedia vorgegebene Ansatz ist sehr flexibel und erlaubt einen hohen Grad der Wiederverwendung der Fragmente. Die oben dargestellte List.jsp enthält keinen Bezug zu unserem Article und kann für alle Objekte verwendet werden, die in einer Liste dargestellt werden sollen. Der ViewDispatcher von CoreMedia kümmert sich dann darum, welche JSP dann für die einzelnen Einträge eingebunden werden soll.
Um die Last auf den Content Server zu reduzieren, kann ein konfiguratives Caches aktiviert werden. DataViews, die eine Ebene über den Contentbeans liegen, werden dann im Speicher gehalten und enthalten mit den Ergebnissen vorbefüllte Beans, die nicht mehr auf den Content Management Server zugreifen müssen. Dieser Objekt-Cache unterscheided sich von den oft in Content Management Systemen eingesetzten HTML-Fragment-Cache.
Zusammenfassung
Obwohl in diesem Artikelt nur eine kurze Einführung erfolgen kann, sollte man sehen können, dass CoreMedia für Entwickler ein angenehmes System ist. Die verteilte Natur macht es nicht nur skalierbar sondern hat auch Auswirkungen auf die Entwicklung: Wenn man für die CAE entwickelt, muss auch nur in dieser Komponente Code geändert werden. Der schwergewichtigere Content Server muss nur einmalig gestarted werden, die eigentliche Arbeit erfolgt dann mit der leichtgewichtigeren CAE, die über das Maven-Jetty-Plugin gesteuert werden kann. Ein Neustart dauert nicht lange, somit hat man deutlich kürzere Entwicklungszyklen. Die JSPs sind klar strukturiert und benötigen mittlerweile kaum Scriptlet-Code. Da der Großteil der Applikation auf Spring MVC basiert, kann bestehendes Entwicklerwissen leicht wiederverwendet werden.
No Comment