Das wird wieder eine intensive Woche:

1. •Umbau meines OSGI Enterprise Servers: Declarative Services anstatt ServiceTracker
   

2. •openArchitectureWare 4.3.1RC1 ist erschienen und muss getestet werden mit meinen Modellierungstemplates
   

3. •Weitere Tests von Eclipse 3.5M3 durchführen: PDE - Unterstützung für Declarative Services, Cycles in 3rd Party Bundles
   

4. •Entwicklung von redView (Riena - EMF - Dynamic Views) und Integration in meinen Modellierungsworkflow
   

Aber jetzt zum Thema dieses Blogs:

Dependencies und Services in OSGI Enterprise Anwendungen

Wer meine Blogserie „HowTo Build an OSGI Enterprise Server“ verfolgt, hat im letzten Beitrag gesehen, dass es bei den vielen Abhängigkeiten sehr schwierig wird, das alles mit einem ServiceTracker zu managen. Daher werden die dort definierten Anforderungen alternativ soweit möglich und sinnvoll mit Declarative Services umgesetzt.

PDE Tooling

Das erste, was sofort beim Arbeiten mit Declarative Services auffällt, ist das fehlende Tooling: wir müssen die Service - Component in einer XML Datei beschreiben:

... und einen Verweis auf die Service Komponenten in der MANIFEST.MF eintragen:

Ab Eclipse 3.5 wird dies besser: PDE Tooling unterstützt Declarative Services :-)

Managing Dependencies

Unter OSGI ist die Verwaltung der Abhängigkeiten eine wichtige Sache und nur eine gut durchdachte Struktur ergibt eine gute Anwendung.

Bisher kennen wir Abhängigkeiten über Import-Package oder Require-Bundle. Diese Abhängigkeiten können wir uns auch anzeigen lassen.

Klassisch als Plug-In - Dependencies:

oder visuell:

(hier ist die Updatesite des Graph Visualization Plug-Ins)

Aber die Bundle - Abhängigkeiten sind nur die eine Seite der Wahrheit, denn sie berücksichtigt nicht die Service - Abhängigkeiten.

Betrachten wir das DataSource Beispiel (s.o.):

Wir haben Abhängigkeiten: Der DataSourceService wird nur zur Verfügung gestellt, wenn jeweils exakt ein Service vom Typ Ejb3ServerComponentsService und JDBCPoolComponent vorhanden ist. Diese beiden Services sind in zwei anderen Bundles deklariert.

Wenn wir in der Service Komponente für diese Services bind / unbind Methoden definiert hätten, dann wären auf diesem Wege Bundle - Abhängigkeiten über Import-Package entstanden.

Bisher habe ich noch kein Tool gefunden, das Service - Abhängigkeiten für Equinox visuell aufzeigt.

Die Thematik ist aber noch wesentlich umfangreicher, denn wir haben verschiedene Strategien, um mit OSGI Services umzugehen:

1. •Declarative Services (wie hier beschrieben)
   

2. •ServiceTracker
   

3. •Riena-Service-Injection
   

4. •...
   

Als Architekt benötige ich den Überblick über Bundles, Services und deren Abhängigkeiten. Daher werde ich in meinem modellgetriebenen Serverprojekt den anderen Weg gehen und die Abhängigkeiten modellieren.

Dann mit openArchitectureWare daraus die Service - Komponenten als XML - Datei erzeugen oder Javacode für ServiceTracker, bzw. Riena - Injection je nach gewählter Strategie.

Aber dies ist ein Thema für einen anderen Blogeintrag ;-)

Declarative Services trace - debug - log

Während des Refactorings meines Serverprojekts bin ich natürlich an den Punkt gekommen, wo ich mich gefragt habe, warum bestimmte deklarative Serviceabhängigkeiten nicht aufgelöst wurden ;-)

Mit Unterstützung der Equinox - Newsgroup und intensivem Googeln habe ich ein paar wichtige System Properties kennengelernt, die ich in der Dokumentation nicht gefunden habe:

1. •equinox.ds.debug=true schaltet den Debugmode ein
   

2. •equinox.ds.print=true gibt die Logausgaben auf die Konsole - benötige ich nicht, da ich die LogService Ausgaben abfange und logge (s.a. Blogserie Logging)
   

3. •equinox.ds.perf=true gibt in ms die Ausführungszeiten aus
   

4. •equinox.scr.waitTimeOnBlock=10000 gibt an, wieviel ms equinox.ds warten soll, bis eine Service Komponente erstellt wurde. War sehr hilfreich, als einige 3rdParty Komponenten im DEBUG Modus Zeiten von mehr als 50000 ms benötigten.
   

ServiceTracker vs Declarative Services

Kann ein Service Tracker komplett durch Declarative Services ersetzt werden ? Nein - das geht leider nicht.

Im ServiceTracker gibt es Zugriff auf alle Methoden eines Services - bei den Declarative Services kann man aber z.B. im target - Filter nur auf die Service Properties zugreifen, die der ServiceRegistry zur Verfügung stehen.

Soweit ein erster Bericht über Declarative Services - vielleicht entwickelt sich auch aus diesem Thema eine Blogserie - ich denke es ist interessant für viele Projekte.

Wen die Thematik von OSGI Enterprise Anwendungen interessiert, sei auf meine Blogserien hingewiesen.

Ausserdem habe ich einige Submissions zur EclipseCon 2009 eingereicht -

Wer meine Erfahrungen live erleben möchte: Kommentare sind willkommen ;-)