Sicher wird sich der eine oder andere fragen, was mit Spling denn nun schon wieder gemeint ist... Nun, die Auflösung des Rätels ist relativ einfach:
Spring + Sling = Spling
Was ist aber die Geschichte hinter dieser Gleichung?
Wir bei namics haben in der Vergangenheit viel Erfahrung in Projekten mit Day Communiqué (CQ) gesammelt. Nicht zuletzt in grossen komplexen Projekten stand das Projektteam oft vor der Entscheidung, auf welchem Weg bestehende oder parallel neu zu entwickelnde Applikationen generell in CQ einzubinden sind. Egal welcher Weg / Ansatz auch gewählt wurde. Eines war sicher... steinig und mit vielen Fallstricken sowie manueller Handarbeit würde er werden.
Seit Anfang dieses Jahres sind wir Partner von SpringSource, der Gründerfirma des bekannten und gleichnamigen Frameworks. Mit Spring arbeiten wir bei namics schon fünf Jahre und haben viele Projekte damit umgesetzt. Da liegt es natürlich auf der Hand zu schauen, ob es künftig bessere und einfachere Ansätze der Integration gibt.
Also haben wir uns letzten Donnerstag zusammengesetzt. Wir heisst in diesem Fall Alex und Michael, beide von Day Software AG, sowie Jan und ich. Und wie es sich gehört, haben wir auch kräftig vom Witheboard im Sitzungszimmer von Day gebrauch gemacht. Visuelles Resultat war:
In Worten gafasst sind wir zum Schluss gekommen, dass insbesondere mit CQ in der neuen Version 5 Integrationen - egal ob Content oder Applikationen - um einiges einfacher zu realisieren sind. Weshalb?
Im Wesentlichen sind es zwei ausschlaggebende Punkte, welche dem Entwickler das Leben künftig einfacher machen wird (oder besser gesagt, wir hoffen es... :-)). Die magischen Technologien dazu heissen OSGi und RESTful HTTP-API, welche je nach Integrationsart zum Zuge kommen.
Das führt uns gleich auch hin zu den Integrationsarten, welche wir künftig sehen. Nach eingehenden Diskussionen stehen im wesentlichen zwei Arten im Vordergrund.
Spring Anwendung integriert in einer Sling-Anwendung (z.B. CQ 5)
CQ 5 wird standardmässig mit einer OSGi-fähigen Runtime (Apache Felix) ausgeliefert. Das bedeutet, künftige Anwendungen können beispielsweise mit Spring Dynamic Modules als OSGi-Bundle realisiert und in die CQ 5 Runtime deployed werden. Damit ist es problemlos möglich, beispielweise Anwendungen oder Anwendungsteile, welche Legacy-Daten integrieren müssen, in ein CQ-Deployment aufzunehmen.
Content aus CQ 5 in einer (Spring) Applikation integrieren
Dieser Fall tritt insbesondere dann auf, wenn Content, der redaktionell im Content Management System verwaltet wird, in einer anderen (Spring) Applikation verwendet werden soll. Hier bietet CQ 5 neu standardmässige Defaulthandler, welche auf einen RESTful HTTP-Request mit unterschiedlichen Formaten antworten können. Bislang implementiert ist ein JSON Handler, der also im JSON-Format antwortet. XML wird künftig auch unterstützt werden. Was wir also bei namics bislang immer selbst implementiert haben, wird ab der Version 5 standardmässig unterstützt.
Eindruck
Zum Abschluss vielleicht noch ein kurzes Statement zum ersten Eindruck von CQ 5 von mir. Da ich mich bislang bei namics eigentlich mehr mit klassischer Applikationsentwicklung mit Spring und weniger mit CQ beschäftigt habe, stütze ich mein Eindruck an dieser Stelle auch eher auf die Technologie ab. Ich bin überzeugt, dass Day Software AG mit der neuen Version von CQ einen grossen Schritt in die richtige Richtung unternommen hat. Was mit der Standardisierung vom Content-Repository (JSR 170) begonnen hat, wird jetzt konsequent bis hin in die Runtime von CQ weitergeführt. Die Entscheidung, CQ 5 komplett als OSGi-Runtime auszuliefern, ist meiner Meinung nach richtig und für Integratoren wie wir es sind, sehr hilfreich.
Wie sich die neue Version dann auch in Projekten anfühlt und bewährt, werden wir sicher bald sehen... :-)
