Namics auf dem Hybris Summit 2014 (3)

hybris Wrap-Up and Q&A

Nachdem am ersten Tag alle Teilnehmer gemeinsam die gleichen Präsentationen lauschen durften, war am zweiten Tag die Themenvielfalt breiter abgestützt. Neben dem Business-Track, welcher an der gleichen Location stattfand, gab es parallel im The Westin Grand Hotel München zwei weitere … Weiterlesen

OSGi Webapplikation mit SpringSource dm Server

In meinem letzten und auch aktuellen Projekt habe ich mich mit dem SpringSource dm Server auseinander setzen dürfen. Aus diesem Grund habe ich hier einmal einen kurzen Überblick zusammengetragen. Welcher auch Teil meines Vortrages bei der Trivadis Java Lounge war.

OSGi Framework
Das OSGi Framework erleichtert Anwendungen und ihre Dienste zu modularisieren und über eine Registry zu verwalten. Ein besonderer Punkt ist die parallele Verwendung mehrerer Versionen eines Javatypes und die Möglichkeit Bundles zur Laufzeit einzuspielen, zu starten, zu stoppen oder zu entfernen. D.h. ich kann beispielsweise während des Betriebs eine neuere Version des Bundles einspielen und danach die alte Version entfernen, ohne dass ein Unterbruch entsteht. Zudem kann ich Services welche mein Bundle bietet, über die Registry innerhalb des OSGi Kontext zur Verfügung stellen. Jedes andere Bundle kann sich dann über das Verzeichnis diesen Dienst holen.

SpringSource dm Server
Das OSGi Framework Equinox gibt es schon seit längerer Zeit auf dem Markt und ist beispielsweise Basis für die Eclipse Entwicklungsumgebung. Seit letztem Jahr ist mit dem SpringSource dm Server nun auch eine Plattform für Webapplikationen vorhanden. Das Herz des dm Server ist der dm Kernel welcher auf das Equinox Framework aufsetzt und dieses erweitert. Zudem beinhaltet der Server einen Tomcat als Servlet Container und die bekannten Spring Technologien.

Grundlagen
Auf dem dm Server können folgenden Formate deployed werden.

  • reine OSGi Bundle als JAR
  • Web Application Archive als WAR
  • Web Bundle als JAR
  • Platform Archive als PAR

Das Web Bundle und das Platform Archive (PAR) sind dm-spezifische Formate und können nur auf diesem Server eingesetzt werden. Das Web Bundle ist im Grunde ein reines OSGi Bundle mit dm-spezifischen Manifesteinträgen. Das PAR ist ein Packaging Format für alle Bundles einer Applikation. Somit können mehrere Bundle zusammengefasst werden und mit einem einzigen Deployment auf den Server aufgespielt werden. Zu beachten ist, dass ausserhalb des PARs, nicht auf exportierte Packages eines enthaltenen Bundles zugegriffen werden kann. Somit ist es nicht möglich auf Konfigurationen etc. eines anderen PARs zuzugreifen.

i-f6be6e1397e945be641d4402a78106bb-osgi_par.png

Der Kern eines OSGi kompatiblen Bundles ist die MANIFEST.MF Datei. In diesem Manifest werden die ganzen zu exportierenden und importierenden Packages festgelegt, inklusive der Version. Genau diese Versionierung erlaubt es uns mehrere Versionen parallel in Betrieb zu nehmen. Wir haben die Möglichkeit, keine Version anzugeben und somit die aktuellste auf dem Server verfügbare Version zu verwenden, auf einzelne Versionen zu fixen oder mit Versionsbereiche zu arbeiten.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.namics.apps.sample
Bundle-Version: 1.0.2
Bundle-Name: Namics–Sample Application
Bundle-Description: Sample Application
Import-Package: org.springframework.osgi.web.context,
 org.springframework.osgi.web.servlet,
 com.namics.apps.sample.domain;version=“1.0.2″,
 com.namics.apps.sample.service;version=„1.0.2″,
 com.namics.apps.sample validation;version=“1.0.2″,
 com.namics.apps.sample.utils;version=“1.0.2″
Export-Package: com.namics.apps.sample.model=“1.0″
Import-Library: org.springframework.spring;version=“[2.5.2,2.5.4)“

In diesem Beispiel wird das Servlet Package in der aktuellsten Version verwendet, das Validation Package der Applikation genau mit der Version 1.0.2 und die Spring Library ab Version 2.5.2 bis und ohne Version 2.5.4. (Zu beachten sind die Klammern).

Toolunterstützung
Für die Applikationsentwicklung auf dem dm Server bietet sich die SpringSource Tool Suite (STS) an. Ab sofort auch in der Version 2.0 zu haben. Neben der Konfigurationsübersicht des dm Servers und dem Manifesteditor gibt es auch noch den Repository Browser für den Zugriff aufs SpringSource Enterprise Bundle Repository. Über dieses Repository ist es möglich OSGi kompatible Bundles zu beziehen und auf den dm Server zu laden. Für das Repository gibt es auch ein sehr übersichtliches, sauber strukturiertes und informatives Webinterface. Die 2.0er Version der STS bietet noch ein paar neue Features betreffend dem dm Server Handling. So ist neu auch eine Übersicht über alle eingespielten Bundles inklusive des aktuellen Status vorhanden. Zusätzlich kann man sich auch die Abhängigkeiten von Services oder Bundles grafisch aufzeichnen lassen. Eine Server Konsole welche ein zusätzliches Telnet Programm überflüssig machen ist ebenfalls vorhanden.
Weil wir für den Buildprozess Maven einsetzen, sind wir auch noch über folgende zwei Plugins gestolpert, maven-bundle-plugin und maven-par-plugin, welche für die Bundle und PAR Erstellung genutzt werden.

Da der dm Server ein sehr neues Produkt ist und auch noch nicht an vielen Orten in produktiven Projekten im Einsatz ist, ist leider auch das Tooling noch nicht so vielfältig und ausgereift. Die Betonung liegt auf noch, denn hier tut sich wirklich so einiges in letzter Zeit, wie mein alleine bei der STS sieht. Da SpringSource seine Bemühungen momentan eher in die IDE investiert ist die Unterstützung ausserhalb der Entwicklungsumgebung eher dürftig. So ist es beispielsweise über das Webinterface des Servers nicht möglich den Status eines Bundles zu beeinflussen, ausser man löscht es gerade komplett vom Server. Auch die Abhängigkeiten etc. sind hier nicht ersichtlich.

Probleme, Grenzen, Möglichkeiten
In folgenden Abschnitten werden ein paar Aspekte bezüglich dem Handling und den damit verbundenen Hürden aufgezeigt.

Bundle nicht OSGi konform – was nun?
Braucht man für sein Projekt ein Bundle welches noch nicht auf dem OSGi Stand ist, hat man folgende zwei Möglichkeiten. Die erste Variante, man bringt seinen Wunsch bei SpringSource an und hofft, dass sie die Arbeit übernehmen und es in ihr Enterprise Repository integrieren. Das ist natürlich Abhängig von der Verbreitung des gewünschten Bundles. Die zweite Variante besteht darin, selber Hand anzulegen und sich das OSGi kompatible Manifest zu erstellen. Hierfür gibt es das sehr nützliche bnd-Tool von Peter Kriens. Ein kurzer Blick auf den Blogeintrag von Costin Leau kann auch nicht schaden.

Eine eigene log4j Konfiguration
Der dm Server besitzt ein Logging welches über die dm Server Loggerkonfiguration gesteuert wird. Da es nur eine Instanz des Loggers gibt, wird auch nur eine einzelne Konfigurationsdatei berücksichtig. Somit ist eine eigene log4j Konfiguration, mit seinem Bundle auszuliefern, nicht möglich. Eine mögliche Lösung ist die Kapselung seines eigenen Loggers innerhalb eines PARs. Das PAR besitzt einen separaten Classloader, somit ist es möglich einen eigenen Logger zu konfigurieren, sofern man die benötigten JARs für das Logging im Package Archive kapselt.

(Momentan) keine JNDI Unterstützung
Zum jetzigen Zeitpunkt gibt es leider noch keine Unterstützung des Java Naming and Directory Interface (JNDI). Ein möglicher Ansatz ist beispielsweise eine DataSource welche man sonst über die JNDI zur Verfügung gestellt hat, in einem Bundle zu konfigurieren und anschliessend diese über die OSGi Registry im Kontext zu veröffentlichen. Dies hat sogar den Vorteil ohne einen Serverneustart zusätzliche Einträge hinzuzufügen.

Konfiguration über globale Properties
Hier besteht der Ansatz darin die Properties ebenfalls über die Registry zu veröffentlichen. Je nach Anwendungsfall kann man sich seine PropertiesFactory nach eigenen Bedürfnissen erstellen.

Properties mit seiner eigenen Factory einlesen…

<bean id="properties" class="com.namics.apps.common.config.EnvironmentPropertiesFactory">
<property name="propertiesPath" value="classpath:env.properties" />
</bean>

…und in die Registry eintragen.

<osgi:service interface="java.util.Properties" ref="properties" />

In einem beliebigen Bundle einbinden…

<osgi:reference id="propertiesOsgi" bean-name="properties" interface="java.util.Properties" />

…als Platzhalter Konfigurator verwenden…

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="properties" ref="propertiesOsgi" />
</bean>

…und wie gewohnt darauf zugreifen

<bean id="proxy" class="com.namics.ProxyFactoryBean">
<property name="serviceUrl" value="${proxy.serverUrl}" />
</bean>

Eckdaten zum Projekt
Beim letzten Projekt ging es um ein business2business Portal welches diverse Services wie Benutzer-, Konto- oder Dokumentenverwaltung zur Verfügung stellt. Die Authentifizierung geschieht über einen Microsoft ISA Server nach dem Single Sign-On Prinzip. Für das Frontend kam CQ5 von Day zum Einsatz, welches auf dem Apache Felix Server läuft.Die ganzen Services wurde im angesprochenen SpringSource dm Server realisiert. Die Services haben dabei Zugriff auf einen Microsoft SQL Server und ein SAP System. Anfangs war eigentlich gedacht, die ganzen Services auf dem ebenfalls OSGi kompatiblen Apache Felix zu implementieren. Doch nach einer Evaluationphase schien uns das Produkt, für unser Vorhaben, weniger ausgereift zu sein als der dm Server von SpringSource. Die Kommunikation zwischen CQ5 auf Apache Felix und den Services auf dem dm Server, bewerkstelligten wir über das Hessian Binary Web Service Protokoll, was hervorragend klappte.

i-9afcc8007f9acc090525ac2b1919fcf9-osgi_projekt_aufbau.png

Projektverlauf
Da bis dahin noch niemand wirklich Erfahrungen mit dem dm Server gemacht hat, haben wir uns in einem kleinen Team von drei bis vier Leuten etwas intensiver mit dem Produkt beschäftigt. Ziel war ein Protyp der alle eingesetzten Mittel und Technologien umfasste. Um so einen kompletten Durchstich vom Browser bis aufs Endsystem des Kunden zu testen. Dabei galt abzuklären wo die grossen Hürden stehen und wo noch zusätzliche Abklärungen notwendig waren. Schlussendlich wurde mit den gemachten Erfahrungen das Grundgerüst für die Applikation gelegt. Sprich Konfiguration, Logging, Security, Bundleaufteilung etc. Durch den modularen Aufbau und Trennung der einzelnen Services war es möglich auch in einer grösseren Entwicklergruppe unabhängig zu arbeiten. Was aber zwingend das angesprochene Grundgerüst voraussetzte. Mit all diesen Massnahmen war es schliesslich möglich, mit rund 15 Leuten, innerhalb von zweieinhalb Monaten, die vom Kunden gewünschten Ziele zu erreichen. Durch die fehlenden Erfahrungen auf unserer Seite und den speziellen Eigenheiten des dm Server auf der anderen Seite, waren auch während der Implementationsphase, zum Teil sehr zeitintensive Nachforschungen nötig.

Fazit
Das Tooling wird stetig verbessert und lässt so noch auf einiges hoffen. Doch schon jetzt ist es möglich Projekte erfolgreich durchzuführen. Mit dem Ausbau der Unterstützung wird es aber sicher noch komfortabler werden. Wünschenswert ist hier sicher die Unterstützung ausserhalb der SpringSource Tool Suite.
Da das Produkt dm Server sehr neu und der Einsatz in Projekten sich in Grenzen hält, ist man mit seinen Problemen meistens der Erste. Momentan ist man sicher noch auf den einen oder anderen Workaround angewiesen. Die Problematik besteht eher darin, sich an einem Workaround festzuhalten, weil man nicht mitbekommen hat, dass gewisse Unterstützungen unterdessen implementiert bzw. integriert wurden.
Das Deployment verläuft im Normalfall stabil, hat aber zum Teil auch seine Aussetzer. Zur Laufzeit selber ist der Server sehr stabil, so konnte während des Betriebs keine Instabilität festgestellt werden.
Was sich schlussendlich bewährt hat und wie man die Vorteile von OSGi eventuell besser nutzen kann, wird sich mit den Erfahrungen und Erkenntnissen aus dem Livebetrieb ergeben.

Im Grossen und Ganzen ein gelungener Wurf, auch wenn noch an der einen oder anderen Schraube gedreht werden muss.