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


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


interface_1.0.0

osgi>



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



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



>> 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:




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ürdenZugriffaufdenüberRMI remote zugreifbaren Service (…accessor.rmi)


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:



•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“.

Technology

Eclipse Magazin 16 - Die Stärke der Drei