Eclipse Magazin 16 - Die Stärke der Drei
-
Upload
heiko-seeberger -
Category
Technology
-
view
1.200 -
download
1
Transcript of Eclipse Magazin 16 - Die Stärke der Drei
74 www.eclipse-magazin.deeclipse magazin Vol. 16
Spring, OSGi und RCPRich Clients
Die mit dem Eclipse-3.0-Release einge-führte Eclipse Rich Client Platform
(RCP) hat sich seit ihrer Veröffentlichung im Jahre 2004 als eine leistungsfähige Plattform für die Entwicklung von Java-basierten Rich Clients erwiesen [1]. Die Kombination aus modularem Aufbau, flexibler Erweiterbarkeit und aktiver Open Source Community trug dabei maßgeblich zu diesem Erfolg bei. Zwei dieser Erfolgsfaktoren lassen sich heu-te auf die Entscheidung zurückführen,
OSGi als Basis des Eclipse-Modularisie-rungskonzepts ausgewählt zu haben [2]. Die in OSGi abgebildeten Komponenten der Bundles (Java-Archive mit jeweils eigenem Classloader und OSGi-spezi-fischen MANIFEST.MF-Einträgen) sind technische Basis für die als Plug-ins be-zeichneten Komponenten, aus denen sich jede RCP-Applikation zusammensetzt. Bei der herkömmlichen Eclipse-RCP-Entwicklung steht dem Programmierer bereits eine breite Palette an Framework-
Funktionalitäten und -Komponenten zur Verfügung (z.B. Views, Perspektiven, MVC-Konstrukte, Updatemechanis-mus). Über diese Framework-Vorgaben hinaus stellt sich aber die Frage nach einem einheitlichen Strukturierungskon-zept für die fachlichen Komponenten der zu erstellenden Anwendung. Wie struktu-riere ich meine Domänenlogik am über-sichtlichsten und effizientesten?
Strukturierung von Domänenlogik: Spring und OSGiIn den vergangenen Jahren lautete die Antwort auf die Frage nach der Ordnung in der eigenen Java-Applikation immer häufiger „Spring“. Das Spring Frame-work [3] mit seinem leichtgewichtigen Applikationscontainer, auf Basis der Konzepte Dependency Injection [4] und AOP [5], liefert dabei einen Strukturie-rungsansatz für POJOs, der sich komfor-tabel in eigenen Applikationen nutzen lässt. Interessant ist dabei insbesondere, dass sich diese Aussage nicht nur für neu entwickelte Applikationen treffen lässt,
Spring trifft auf OSGi und RCP
Die Stärke der Drei >> alexander thurow und heiko seeberger
Mit dem Zusammenrücken von Spring und OSGi durch Spring Dynamic Modules (DM) ergeben sich neue und vielversprechende Möglichkeiten für die Eclipse-RCP-Entwicklung. Im Kern definiert Spring DM dabei eine einfach zu nutzende Integrationsschicht für die Framework-Welten von Spring und OSGi. Aufsetzend auf dieser Schicht kann der Entwickler zukünftig mit deutlich weniger Aufwand flexible RCP-Applikationsarchi-tekturen erstellen.
Quellcode auf CD!
75www.eclipse-magazin.de eclipse magazin Vol. 16
Rich ClientsSpring, OSGi und RCP
sondern auch für bestehende Altapplika-tionen.
Neben Spring lässt sich mittlerweile ein neuer Trend hin zur OSGi-basierten Modularisierung von Applikationslogik identifizieren. Diese Entwicklung wird unmittelbar verständlich, wenn man das von OSGi definierte Komponen-tenmodell der Bundles betrachtet. Im Kern ermöglicht dieses Modell eine lose gekoppelte Applikationsarchitektur, in der einzelne Komponenten zur Laufzeit austauschbar/aktualisierbar sind sowie verschiedene Versionen einer Kompo-nente parallel betrieben werden kön-nen. In Kombination mit der von OSGi definierten Servicearchitektur können leistungsfähige und flexible Applika-tionsarchitekturen realisiert werden. Neuerdings hält OSGi mit diesem Leis-tungsspektrum auch im Bereich der Ap-pliktionsserverarchitekturen auf breiter Front Einzug (derzeit: IBM WebSphere 6.x, JOnAS 5.x; in Zukunft: Sun Glass-Fish, JBoss AS und BEA WebLogic).
Im konkreten Anwendungskontext der clientseitigen RCP-Entwicklung ist OSGi hingegen ein alter Bekannter. Bei der Entwicklung von RCP ist von vorn-herein konsequent auf OSGi gesetzt wor-den: Jedes Eclipse-Plug-in ist gleichzeitig ein OSGi-Bundle. Bei der Modularisie-rung einer zu erstellenden RCP-Applika-tion kann demnach out-of-the-box auf das volle Leistungsspektrum von OSGi zugegriffen werden. Schaut man genauer hin, so lässt sich sogar feststellen, dass die RCP zugrunde liegende OSGi-Implemen-tierung Eclipse Equinox die Referenz- implementierung der OSGi-R4-Spezifi-kation ist [6]. Während OSGi also über die Integration in das Framework unmit-telbar im Zugriff des RCP-Entwicklers liegt, hat sich der Sachverhalt im Bereich von Spring bisher deutlich anders darge-stellt: Jede Nutzung von Spring musste ohne Framework-Unterstützung voll-ständig „zu Fuß“ realisiert werden. Kon-kret bedeutete das, dass der Entwickler seine Spring-Anbindung mithilfe von klassischem „Boilerplate-Code“ selbst realisieren musste. Mit Spring DM än-dert sich dieser Sachverhalt nun grund-legend.
Spring Dynamic Modules: RCP, OSGi und SpringZum einen sind mit der Veröffentlichung von Spring 2.5 die Framework-Welten
von Spring und OSGi schon deutlich nä-her zusammengerückt. Ab dieser Version sind alle mit Spring ausgelieferten JAR-Dateien gleichzeitig OSGi Bundles und somit unmittelbar in OSGi-Ablaufumge-bungen installierbar und nutzbar. Diese komfortable Neuerung ist möglich, da sich klassische JAR-Dateien und OSGi-Bundles nur durch zusätzliche Einträge in der MANIFEST.MF-Konfigurationsdatei unterscheiden, die jede JAR-Datei enthält.
Zum anderen stellt Spring nun mit Spring Dynamic Modules eine Techno-logie zur Verfügung, die eine Integrati-onsschicht zwischen Spring und OSGi definiert [7]. Die an die Ablaufumgebung gestellten Anforderungen sind (vorzugs-weise) Spring 2.5, eine Java-VM >= 1.4 sowie eine OSGi-R4-Implementierung (z.B. Equinox 3.x, Apache Felix 1.x, Knopflerfish 2.x). Die Vorteile, die für den RCP-Entwickler mit Spring DM einhergehen, lassen sich wie folgt zusam-menfassen:
•StandardisiertesVorgehenfürdieDe-finition von Spring-Kontexten pro Bundle
•AutomatischesErkennenvonSpring-Kontextdefinitionen pro Bundle
•DeklarativerExportvonBundle-loka-len Spring Beans als OSGi-Services und dadurch Bundle-externe Zugriffsmög-lichkeiten
•IntegrationvonSpring-Kontext-undOSGi-Lebenszyklus
•Deutlichweniger„Boilerplate-Code“
Im Klartext bedeutet dies nichts anderes, als dass Spring DM dem OSGi-Entwick-ler ein standardisiertes Modell für die Nutzung von Spring an die Hand gibt. Die Verwendung von Spring in OSGi-basierten Applikationen wird damit für
den Entwickler deutlich leichter, trans-parenter und – wenn man so will – auch eleganter.
Technische Realisierung von Spring DMRealisiert wird die Integration über eini-ge, mit der eigenen Applikation zusätz-lich auszuliefernde Bundles. Werden die Spring DM Bundles zur Laufzeit vom OSGi-Container gefunden und gestartet,
Abb. 1: Benutzerin-terface des Spring-DM-basierten Rich
Clients
Listing 1
Start des Spring DM-basierten OSGi-Serverprozesses
INFO: Discovered configurations {osgibundle:/
META-INF/spring/*.xml} in bundle [Rmi Publisher
Plug-in (com.weiglewilczek.springosgi.
service.publisher.rmi)]
…
INFO: Binding service ’MyRmiPublishedService‘ to RMI
registry: RegistryImpl[UnicastServerRef [liveRef:
[endpoint:[192.168.1.201:1199](local),objID:
[0:0:0, 0]]]]
osgi> ss
Framework is launched.
Id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900
1 ACTIVE org.springframework.bundle.osgi.
extender_1.1.0
2 ACTIVE com.weiglewilczek.springosgi.service.
publisher.rmi_1.0.0
3 ACTIVE com.weiglewilczek.springosgi.service.
implementation_1.0.0
4 ACTIVE org.apache.commons.logging_1.0.4.
v20080605-1930
5 ACTIVE org.springframework.bundle.osgi.core_1.1.0
6 ACTIVE org.eclipse.equinox.common_3.4.0.
v20080421-2006
7 ACTIVE org.springframework.bundle.osgi.io_1.1.0
8 ACTIVE org.springframework.bundle.spring_2.5.5
9 ACTIVE com.weiglewilczek.springosgi.service.
interface_1.0.0
osgi>
76 www.eclipse-magazin.deeclipse magazin Vol. 16
Spring, OSGi und RCPRich Clients
sorgen sie dafür, dass in OSGi-Bundles hinterlegte XML-Spring-Kontexte ge-laden werden. Somit kann jedes Bundle über einen eigenen Spring-Kontext ver-fügen, der die Erzeugung und Konfigu-ration der Objekte – im Spring-Jargon „Beans“ genannt – innerhalb des Bundles übernimmt. Wirklich interessant wird es dann aber mit Spring DMs Möglich-keiten zum deklarativen Export von Bundle-lokal verwalteten Spring Beans. Über Einträge in den Spring-Kontextde-finitionen können Beans in die OSGi Ser-vice Registry exportiert, respektive aus dieser importiert werden. Für den Im- und Export definiert Spring DM einen zusätzlichen XML Namespace. Abge-rundet wird Spring DMs Feature-Spek-
trum durch eine Integration der OSGi- und Spring-Kontextlebenszyklen. Als Resultat erhält man dann, Spring DM sei dank, eine vorwiegend über Spring-XML-Kontextdefinitionen konfigu-rierte Applikation und erspart sich eine erhebliche Menge an Boilerplate-Code. Im folgenden Anwendungsbeispiel wer-den RCP und Spring DM kombiniert, um die Vorteile der auf dieser Basis möglich werdenden Anwendungsentwicklung herauszuarbeiten.
Das AnwendungsbeispielAls Beispielapplikation dient eine ein-fache RCP-Anwendung, mit der der Be-nutzer einen OSGi-Service aufrufen kann. OSGi-Services sind ein Basisleistungs-merkmal von OSGi, das es dem Program-mierer erlaubt, Java-Objekte in einer zentral zugreifbaren Service Registry anzumelden. Das anzumeldende Objekt kann dabei wahlweise unter Angabe des Namens seines/seiner Interface(s) und/oder dem Namen seiner Implementati-onsklasse in der Service Registry abgelegt werden. Serviceclients können dann unter Angabe eines solchen Namens (und opti-onal einigen zusätzlichen Kriterien) eine Referenz auf den angemeldeten Service erlangen. Um das Leistungsspektrum von Spring DM in diesem Zusammenhang zu verdeutlichen, wurde die Applikation so strukturiert, dass sie entweder als her-
kömmlicher Standalone Rich Client oder als Client/Serveranwendung betrieben werden kann. Im Fall des Standalone-Betriebs wird dabei der zu rufende OSGi-Service als Plug-in mit ausgeliefert und lo-kal aufgerufen, während dieser bei Client/Serverkonfiguration remote über RMI in einem OSGi-Serverprozess gerufen wird (Abb. 1, Listing 1).
Um die abgebildete Architektur zu realisieren wurden fünf OSGi-Bundles erstellt:
•BundlefürdasInterfacedesOSGi-Ser-vice (...interface)
•BundlefürdieImplementierungdesOSGi-Service (…implementation)
•BundlezumExportierendesOSGi-Service in eine RMI-Registry (...publis-her.rmi)
•BundlefürdenZugriffaufdenüberRMI remote zugreifbaren Service (…accessor.rmi)
•RCP-Plug-infürdieClientapplikation(…client)
Für den Betrieb der Spring-DM-Appli-kation selbst sind sieben weitere Bundles nötig, die die Funktionalität von Spring DM implementieren, eine Logging-Implementierung mitbringen sowie ei-ne OSGi-Implementierung beisteuern (Abb. 2).
Was die eigentliche Serviceimple-mentierung anbelangt, so ist die Logik für dieses Beispiel trivial. Das Interface des Service enthält nur eine Methode für die Addition zweiter int-Werte. Die Ser-viceimplementierung ist daher nahelie-gend (Listing 2).
Anzumerken ist in diesem Zusam-menhang lediglich, dass Interface und Implementierung in zwei separaten Bundles abgelegt sind. Dieses Vorgehen hat sich bei der Realisierung von OSGi-Services als Best Practice erwiesen, da
Abb. 2: OSGi Bundles der erstell-ten Lösung
Abb. 3: Kontextdefiniti-on im implementation-Bundle
Listing 2
Serviceimplementierung
package com.weiglewilczek.springosgi.service.
internal;
import com.weiglewilczek.springosgi.service.
MyService;
public class MyServiceImpl implements MyService {
public int add(int a, int b) {
return a + b;
}
}
www.eclipse-magazin.de
Spring, OSGi und RCP
nur so das Bundle mit dem Interface für den Zugriff auf einen registrierten Ser-vice benötigt wird. Bundles, die Imple-mentierungen des Interface als Service publizieren, werden dadurch für den Cli-ent nachrangig und transparent.
Serviceregistrierung und -referenzierung mit Spring DMInteressant wird es nun aber, wenn man die Registrierung und anschließende
Referenzierung des Service betrachtet. OSGi-Entwickler müssen aufgrund der dynamischen Umgebung von OSGi da-bei etliches in Betracht ziehen – so kön-nen Bundles zum Beispiel zu beliebigen Zeitpunkten aktiv oder inaktiv werden, aktualisiert oder sogar deinstalliert wer-den. Obwohl das Framework eine API definiert, die einiges an Komplexität ver-birgt (Stichwort: ServiceTracker), ent-steht bei der Arbeit mit OSGi-Services
Unter der Haube
Der eine oder andere Leser wird sich fragen:
Wozu eigentlich Spring DM? Warum nicht
Spring in RCP-Applikationen „ganz normal“
verwenden? Die Antwort darauf lautet: OSGi
bzw. das zugrunde liegende Modularisierungs-
konzept machen Spring DM erforderlich.
Solange eine RCP-Applikation nur aus einem
einzigen Plug-in bzw. Bundle besteht, das
neben den Klassen und Ressourcen der Appli-
kation auch die Spring-Bibliothek(en) enthält,
kann man tatsächlich Spring wie gehabt ver-
wenden, d.h. insbesondere ohne Spring DM.
Allerdings ist dieser Fall wohl akademischer
Natur, denn ein Hauptargument für die Ver-
wendung von Eclipse RCP bzw. OSGi ist – ne-
ben Dynamik und Serviceorientierung – die
Modularisierung, sodass RCP-Applikationen
in der Praxis aus mehreren Bundles bestehen
werden. Und genau das bedeutet das Aus
für den gewohnten globalen Spring-Kontext.
Schließlich werden die zu erzeugenden und zu
konfigurierenden Beans in einer modularen
Applikation auf mehrere Bundles verteilt sein.
Damit Spring diese instanziieren kann, müssen
die entsprechenden Klassen geladen werden
können. Das bedeutet in der OSGi-Welt, dass
die Applikations-Bundles alle Packages, die
Spring-Bean-Implementierungsklassen ent-
halten, exportieren müssen. Das widerspricht
dem Konzept, dass nur öffentliche API – in
der Regel oft Interfaces und Basisklassen – zu
publizieren und die Implementierung privat zu
halten ist, denn schließlich sind Spring Beans
meist (private) Implementierungen von (öf-
fentlichen) Interfaces. Weiterhin benötigt das
Bundle, das den globalen Spring-Kontext er-
zeugen soll, Abhängigkeiten zu allen Bundles
mit Spring Beans. Wenngleich das technisch
möglich ist, so ist es strukturell eher als
„Designfehler“ anzusehen.
Spring DM setzt voll auf OSGi-KonzepteSpring DM löst dieses Dilemma nicht nur, es
geht dabei sogar einen sehr eleganten Weg,
indem es voll auf OSGi-Konzepte setzt.
Zunächst wird der globale Spring-Kontext auf-
gegeben. An seine Stelle treten Bundle-lokale
Spring-Kontexte. Konkret wird für jedes so ge-
nannte „Spring-powered“ Bundle ein eigener
Spring-Kontext auf Basis der Bundle-lokalen
Spring-Konfigurationsdatei(en) erzeugt. Auf
diese Weise wird das OSGi-Konzept der Mo-
dularisierung konsequent auf Spring bzw. den
Spring-Kontext übertragen.
Um dennoch Beans Bundle-übergreifend
nutzen zu können, kommen – wie im Artikel
beschrieben – OSGi-Services zum Einsatz. Das
Ex- und Importieren von Beans erfolgt also mit
„OSGi-Bordmitteln“ und ist daher auch mit der
Dynamik von OSGi bestens verträglich.
Vom Bundle zum „Spring-powered“ BundleWie wird nun ein Bundle ganz konkret zum
„Spring-powered“ Bundle? Dies ist die Aufga-
be eines speziellen Bundles, das Bestandteil
von Spring DM ist: das so genannte Spring DM
Extender Bundle (org.springframework.osgi.bundle.extender).
Sobald dieses installiert und gestartet wird,
analysiert es alle gestarteten Bundles, ob
sie Spring-Konfigurationsdateien enthalten.
Diese können entweder standardgemäß im
Verzeichnis META-INF/spring/ liegen oder
in beliebigen anderen Verzeichnissen, die
über den speziellen Manifest Header Spring-Context spezifiziert werden können. Für jedes
Bundle, das auf die eine oder andere Weise
Spring-Konfigurationsdateien enthält, wird
vom Spring DM Extender Bundle ein Spring-
Kontext erzeugt.
Doch damit nicht genug: Das Spring DM
Extender Bundle verfolgt mittels eines so ge-
nannten BundleListeners das Starten weiterer
Bundles, sodass in der Folge auch neu gestar-
tete „Spring-powered“ Bundles mit ihrem
Spring-Kontext versehen werden.
In diesem Zusammenhang muss hervorge-
hoben werden, dass das Starten von Bundles
für Spring DM eine entscheidende Rolle spielt:
Sowohl das Spring DM Extender Bundle als
auch ein „Spring-powered“ Bundle muss ge-
startet sein, damit ein Spring-Kontext erzeugt
wird. Insbesondere Entwickler von RCP-Appli-
kationen dürften diesem Sachverhalt bisher
weniger Beachtung geschenkt haben, da das
Verwenden der exportierten APIs sowie das
Nutzen von Extension Points ohne das Starten
von Bundles auskommt.
C
M
Y
CM
MY
CY
CMY
K
0808_06_AZ_W_Eclipse_Magazin_rz_Page 1 08.08.2008 10:29:13 Uhr
78 www.eclipse-magazin.deeclipse magazin Vol. 16
Spring, OSGi und RCPRich Clients
einiges an Boilerplate-Code. Setzt man Spring DM ein, so reduziert sich dieser Code erheblich, da Spring DM Bordmit-tel mitbringt, die es ermöglichen, An-meldungen und Referenzierungen von Services in Spring-Kontextdateien aus-zulagern. Wenn man dies anhand des im-plementation-Bundles betrachtet, wird man abweichend von einem klassischen Bundle unterhalb von META-INF einen zusätzlichen Ordner namens spring fin-den (Abb. 3).
Ist nun das bereits oben in der Bundle-Übersicht aufgeführte Spring DM Extender Bundle mit all seinen Ab-hängigkeiten aktiv, so sorgt dieses (stan-dardmäßig) dafür, dass bei jedem aktiv werdenden Bundle ein solcher Ord-ner nach Spring-Kontextdefinitionen durchsucht wird. Jede dort gefundene XML-Datei wird dabei als Kontextde-finition interpretiert. Aus diesen Defi-nitionen wird dann ein Bundle-lokaler Spring-Kontext erzeugt. Dieser un-terscheidet sich strukturell zunächst nicht von einem Kontext aus einer her-
Abb. 4: Kontextdefini-tion im client-Bundle (mit RCP-Applikation)
kömmlichen Spring-Applikation. Wie man Abbildung 3 entnehmen kann, ist danach die Serviceimplementierung MyServiceImpl unter dem Namen mySpringManagedBeanToBeExported als Spring-Bean zugreifbar. Zusätzlich zu dieser Bean-Definition findet sich aber noch ein weiterer (Spring-DM-spezifischer) Eintrag in der Kontext-definition: <osgi:service>. Dieser sorgt für den Export der Bean in die Service Registry. Anstelle des eigenhändig zu erstellenden Codes führt Spring DM hier also eine komfortabel zu nutzende Abstraktionsschicht ein. Spring DM definiert dafür einen zusätzlichen XML Namespace http://www.springframe-work.org/schema/osgi, über den die Spring-DM-spezifische XML-Konfigu-ration ermöglicht wird. Als Best Prac-tice wird in der Spring-DM-Referenz empfohlen, die Kontextdefinition der Bundle-lokalen Spring Beans und die der OSGi-spezifischen Definitionen in (mindestens zwei) separate Kontext-dateien auszulagern. Für das Beispiel
wurde bewusst von dieser Empfehlung abgewichen, um das Beispiel übersicht-licher darstellen zu können.
Betrachtet man die Referenzierung des soeben in der Service Registry ange-meldeten Service, so erwartet einen hin-sichtlich der Nutzung von Spring DM keine Überraschung mehr: Über den Ein-trag <osgi:reference> können in der Ser-vice Registry angemeldete Services in den Bundle-lokalen Spring-Kontext impor-tiert werden. Zusätzlich kann man der Kontextdefinition entnehmen, dass ein <osgi:listener>-Element für den Service registriert wurde. Ein solches ermöglicht es dem Entwickler, Benachrichtigungen über den Lebenszyklus des Service zu er-halten und gegebenenfalls auf solche zu reagieren (Abb. 4).
Auf der Basis von Spring DM lassen sich nun mit überschaubarem Aufwand flexible Applikationsarchitekturen er-stellen. Architekturen wie die unseres beispielhaften Anwendungsfalls „Stand-alone- vs. Client/Serverbetrieb“. Die Mo-dularisierung über OSGi Bundles sowie
Abb. 5: Kontextdefini-tion im clientseitigen accessor.rmi-Bundle
80 www.eclipse-magazin.deeclipse magazin Vol. 16
Spring, OSGi und RCPRich Clients
>> Links & Literatur[1] wiki.eclipse.org/index.php/Rich_Client_Platform
[2] de.wikipedia.org/wiki/OSGi
[3] springframework.org/
[4] en.wikipedia.org/wiki/Dependency_injection
[5] de.wikipedia.org/wiki/Aspektorientierte_ Programmierung
[6] www.eclipse.org/equinox/
[7] www.springframework.org/osgi/
Alexander Thurow ist Software-entwickler und Trainer bei der Weigle Wilczek GmbH in Esslingen am Neckar. Er beschäftigt sich seit drei Jahren mit der Entwicklung von
Enterprise-Applikationen auf Basis von JEE und Eclipse RCP. Kontakt: [email protected].
Heiko Seeberger ist als Technical Director für die Weigle Wilczek GmbH tätig. Sein technischer Schwerpunkt liegt in der Entwicklung von Unter-nehmensanwendungen mit OSGi,
Eclipse RCP, Spring, AspectJ und Java EE. Seine Erfahrung aus über zehn Jahren IT-Beratung und Softwareentwicklung fließen in die Eclipse Training Alliance ein; zudem ist Heiko Seeberger aktiver Committer in Eclipse-Projekten. Kontakt: [email protected].
die Strukturierung der Applikation über Spring (Bundle-lokal) und OSGi-Services (applikationsglobal) geben einem dafür die geeigneten Hilfsmittel zur Hand.
Standalone-KonfigurationFür den Standalone-Betrieb werden neben den Infrastruktur-Bundles von Spring DM und RCP drei der fünf Appli-kations-Plug-ins ausgeliefert:
•BundlefürdasInterfacedesOSGi-Ser-vice (...interface)
•BundlefürdieImplementierungdesOSGi-Service (…implementation)
•RCP-Plug-infürdieClientapplikation(…client)
Dabei liefert und registriert, wie oben schon aufgezeigt, das implementation-Bundle die Spring-Bean-basierte Imple-mentierung für die Service Registry. Das client-Bundle wird danach über den an der Registry angemeldeten ServiceLis-tener über den neu angemeldeten Ser-vice informiert. Dies erfolgt über Aufruf der onBind()-Methode des Listeners. Dort kann dann der RCP-Applikation eine Referenz auf den Service zugewiesen werden (konkret über die Hilfsmethode Activator.setService(MyService)). Im di-rekten Anschluss an diese von Spring DM gesteuerte Initialisierung steht die „Run Service“-Funktionalität in der UI zur Ver-fügung.
Client/ServerkonfigurationFür diese zweite Konfiguration wird die Clientseite der Applikation mit einer abgewandelten Menge von Bundles ver-sehen:
•BundlefürdasInterfacedesOSGi-Ser-vice (...interface)
•BundlefürdenZugriffaufdenüberRMI remote zugreifbaren Service (…accessor.rmi)
•RCP-Plug-infürdieClientapplikation(…client)
Hierbei ist hervorzuheben, dass der Cli-ent in dieser Konstellation die eigentliche Serviceimplementierung nicht enthält. Stattdessen registriert das accessor.rmi-Bundle unter dem bekannten Servi-ceinterface MyService ein RMI-Proxy-Objekt, über das remote mit dem Service kommuniziert werden kann. Genutzt wird hierzu die mit Spring ausgelieferte RMI-Integrationsschicht (Abb. 5).
Auf der Serverseite wird ein OSGi-Prozess gestartet, in dem folgende Bundles laufen:
•BundlefürdasInterfacedesOSGi-Ser-vice (...interface)
•BundlefürdieImplementierungdesOSGi-Service (…implementation)
•BundlezumExportierendesOSGi-Ser-vice in eine RMI Registry (...publisher.rmi)
Neben den zwei bekannten Bundles für das Serviceinterface und dessen Imple-mentation findet sich auf der Serversei-te das Bundle publisher.rmi. In diesem Bundle ist Funktionalität lokalisiert, die dafür sorgt, dass der vom implementa-tion-Bundle registrierte Service in einer RMI Registry für Remote-Zugriffe pu-bliziert wird. Auch in diesem Fall wird die mit Spring ausgelieferte RMI-Inte-grationsschicht genutzt (Abb. 6).
Besonderes Augenmerk sei dabei auf die leeren src-Verzeichnisse der beiden letztgenannten Bundles gelenkt (Abb. 5, 6). Bei dem für die Bundles ge-wählten Implementationsansatz muss
Abb. 6: Kontextdefi-nition im ser-verseitigen publisher.rmi-Bundle
keine Zeile Java-Code mehr geschrie-ben werden.
FazitDie in Spring DM abgebildete Integra-tionsschicht zwischen den Spring und OSGi Frameworks ermöglicht es dem RCP-Entwickler, zukünftig mit deutlich verringertem Aufwand die Vorteile von Spring und OSGi vereint zu nutzen. In Zukunft ist es also keine Wunschvorstel-lung mehr: „RCP powered by Spring“.