Realisierung von Service-Varianten und zustandsbehafteten Services aus Basis von OSGi

OSGi-Einsatzkontext: “SiDiff”Warum OSGi?

Realisierungs-ProblemeLösungsansätze und technische Umsetzung

Zusammenfassung

Realisierung von Service-Variantenund zustandsbehafteten Services

auf Basis von OSGi

Timo Kehrer Sven Wenzel Maik Schmidt

Universität Siegen, Praktische Informatik{kehrer, wenzel, mschmidt}@informatik.uni-siegen.de

OSGi Users’-Forum Treffen 200927.10.2009 @ Eclipse Summit in Ludwigsburg

Timo Kehrer Service-Varianten und zustandsbehaftete Services auf Basis von OSGi



Zusammenfassung

Outline1 OSGi-Einsatzkontext: “SiDiff”

ApplikationsdomäneProblemmotivation

2 Warum OSGi?ArchitekturTechnologische Umsetzung

3 Realisierungs-ProblemeEinführendes BeispielZustandsbehaftete ServicesService-Varianten

4 Lösungsansätze und technische UmsetzungKapselung der OSGi Service-SchichtZustandsbehaftete Services: “ProvideableService”Service-Varianten: “ConfigurableService”Kombination: “ConfigurableProvideableService”




Zusammenfassung










Zusammenfassung


Versionen und Varianten technischer Dokumente

Technische Dokumente mit grafischer Notation gewinnenzunehmend an Bedeutung, bspw.

CAD-DokumenteUML-ModelleMatlab/Simulink-Modelleetc.

Komplexe Dokumente werden in der Regel im Team bearbeitetund in Repositories gespeichertDokumente existieren in mehreren Versionen (Revisionen oderVarianten)Daraus resultieren eine Reihe praktischer Probleme:

Konfigurationsmanagement (Diff/Merge)Analyse von DokumenthistorienClone Detectionetc.




Zusammenfassung


Textuelle Dokumente vs. grafische/graphbasierte Dokumente




Zusammenfassung


Differenzen auf Basis der textuellen Repräsentation




Zusammenfassung


Konzeptuelle Differenzen




Zusammenfassung


Fazit

Text-orientierte Werkzeuge ungeeignet für technischeDokumente mit grafischer Notation

Einsatz grafischer Dokumente und Modelle rasant zunhemend,bspw. im Zuge moderner Entwicklungsparadigmen wie dermodellbasierten Software-Entwicklung (MDA, MDD, MDSD, etc.)

Daher Bedarf für hoch optimierte Verfahren und Werkzeuge fürModelle und grafische Dokumente

→ SiDiff-Projekt (www.sidiff.org)


www.sidiff.org



Zusammenfassung

ArchitekturTechnologische Umsetzung









Zusammenfassung


Workflow (Hier: Diff-Prozess)




Zusammenfassung


Komponenten und Services (Hier: Diff-Applikation, vereinfacht)




Zusammenfassung


Gründe für den Einsatz von OSGi

Architektonische GründeFlexibilität, AustauschbarkeitLose Kopplung von klar definierten Komponenten/Services

Organisatorische Gründe

“Echtes” Geheimhaltungsprinzip auf Komponentenebene:Einhaltung von Konventionen weitestgehend durch dasFramework sichergestelltEffektive Maßnahme um der Degeneration der Architekturentgegen zu wirken

Pragmatische Gründe

Umsetzung des Service-Konzepts auf Basis von JavaNahtlose Integration in die Eclipse IDE




Zusammenfassung

Einführendes BeispielZustandsbehaftete ServicesService-Varianten









Zusammenfassung


3-Wege-Vergleich/-Mischen




Zusammenfassung


Nutzung von Services in verschiedenen Kontexten

Es kann oft vorkommen, dass ein Service gleichzeitig inverschiedenen Kontexten genutzt werden soll.

Problematisch ist dies für zustandsbehaftete Services

Hier kann nicht genau eine Service-Instanz beimOSGi-Framework registriert werden.

Ein erster Lösungsansatz ist die OSGi Service Factory




Zusammenfassung


Die OSGi Service Factory und deren Grenzen

OSGi Service Factory

Die Service Factory ist Bestandteil des OSGi Standards.Kann anstatt des eigentlichen Services beim OSGi-Frameworkregistriert werden.Die eigentliche Service-Instanz wird bei der Anforderung desServices transparent über die Factory erzeugt.

Grenzen der OSGi Service Factory

Die erzeugten Service-Instanzen werden vom OSGi-Frameworkpro anfragendem Bundle gecached.Szenarien, in denen ein Bundle verschiedene Instanzen einesServices erhalten sollen sind damit nicht realisierbar.




Zusammenfassung


Konfigurierbare Services und Service-Varianten

Oftmals benötigen wir Services, die z.B. für einen bestimmtenDokumenttyp konfiguriert werden.

Ein Beispiel ist der ähnlichkeits-basierte Matching-Service, welcherdurch eine Dokumenttyp-spezifische Heuristik konfiguriert wird.

Zudem sollte die Koexistenz von mehreren Service-Instanzen,welche verschieden konfiguriert sind unterstützt werden.

So zum Beispiel beim Einsatz von SiDiff im Rahmen einerEntwicklungsumgebung, welche mehrere Dokumentypenunterstützt.




Zusammenfassung

Kapselung der OSGi Service-SchichtZustandsbehaftete Services: “ProvideableService”Service-Varianten: “ConfigurableService”Kombination: “ConfigurableProvideableService”









Zusammenfassung


Der Service-Helper

Keine direkte Kommunikation mitdem OSGi-Framework über denOSGi-BundleContextService-Helper kapselt die Zugriffeauf den Service-Layer desOSGi-FrameworksAllgemeine Schnittstelle fürAufgaben wie bspw. dieRegistrierung oder das Anfordernvon Services




Zusammenfassung










Zusammenfassung


Definition der Service-Schnittstelle

“Leeres” InterfaceDient als “Marker”im automatischenInstanzi-ierungsprozess

Heißt wie die Service-Schnittstelle trägtdas Suffix Provider.Liegt im selben Paket wie dieService-Schnittstelle.Erbt vom Interface ServiceProvider,getypt auf die Service-Schnittstelle.




Zusammenfassung


Implementierung des Services

Implementierung desDienstes

Erzeugung einer Instanz desDienstes




Zusammenfassung


Bekanntmachen der Service-Implementierung�p u b l i c c l a s s A c t i v a t o r implements B u n d l e A c t i v a t o r {

p u b l i c vo id s t a r t ( Bund l eCon tex t c o n t e x t ) throws E x c e p t i o n {S e r v i c e H e l p e r . r e g i s t e r S e r v i c e P r o v i d e r (

c o n t e x t ,M y S e r v i c e P r o v i d e r . c l a s s ,new M y S e r v i c e P r o v i d e r I m p l ( ) ,nul l , / / DocTypen u l l ) ; / / V a r i a n t

}

p u b l i c vo id s t o p ( Bund leCon tex t c o n t e x t ) throws E x c e p t i o n {}

}� �Registriert wird der ServiceProviderDie Service-Implementierung selbst muss nicht registriertwerdenSie wird über den ServiceProvider bereitgestellt




Zusammenfassung


Verwenden des Services�MyService ms = S e r v i c e H e l p e r . g e t S e r v i c e (

c o n t e x t , \ \ Bund l eCon tex tMyService . c l a s s , \ \ S e r v i c e I n t e r f a c enul l , \ \ DocumentTypen u l l ) ; \ \ V a r i a n t

ms . doSomething ( ) ;� �Der Zugriff auf den Provider und die Instanzierung dereigentlichen Service-Implementierung erfolgt transparent.

Der ServiceHelper prüft, ob der angeforderte Service einProvideableService ist.Wenn ja, wird beim OSGi-Framework ein entsprechendbenannter ServiceProvider (hier MyServiceProvider)gesucht und dessen createInstance()-Methode aufgerufen.




Zusammenfassung










Zusammenfassung


Definition der Service-Schnittstelle

Konfigurierbare Services müssen das InterfaceConfigurableService erweitern.�

p u b l i c i n t e r f a c e C o n f i g u r a b l e S e r v i c e {p u b l i c S t r i n g c o n f i g u r e ( O b j e c t . . . c o n f i g D a t a ) ;p u b l i c vo id d e c o n f i g u r e ( ) ;p u b l i c D i c t i o n a r y < S t r i n g , S t r i n g > g e t P r o p e r t i e s ( ) ;

}� �Die configure()-Methode wird aufgerufen, um den Servicemit beliebigen Daten (Object...) zu konfigurieren.Der Rückgabewert der configure()-Methode ist derDokumenttyp für den die Konfiguration geeignet ist.Da sich der Typ i.d.R. aus den Konfigurationsdaten ableitet, kanner sinnvollerweise nur hier ermittelt werden.




Zusammenfassung


Implementierung des Services

Implementierung unterscheidet sich von “einfachen Services” nurdurch die zusätzlichen Methoden des ConfigurableServicedamit wird der Service-Instanz die Konfiguration übergebenübergeben wird.�

p u b l i c c l a s s M y C o n f i g u r a b l e S e r v i c e I m p l implements M y C o n f i g u r a b l e S e r v i c e

S t r i n g docType ;

p u b l i c S t r i n g c o n f i g u r e ( O b j e c t . . . c o n f i g D a t a ) {/ / . . .re turn docType ;

}

p u b l i c vo id d e c o n f i g u r e ( ) {}

p u b l i c D i c t i o n a r y < S t r i n g , S t r i n g > g e t P r o p e r t i e s ( ) {re turn n u l l ;

}}� �




Zusammenfassung


Bekanntmachen der Service-Implementierung

Registrierung der Schnittstelle und der konkretenImplementierung des konfigurierbaren Services beimServiceHelper

�p u b l i c c l a s s A c t i v a t o r implements B u n d l e A c t i v a t o r {

p u b l i c vo id s t a r t ( Bund l eCon tex t c o n t e x t ) throws E x c e p t i o n {S e r v i c e H e l p e r . r e g i s t e r S e r v i c e C o n f i g u r a t o r (

c o n t e x t ,M y C o n f i g u r a b l e S e r v i c e . c l a s s ,M y C o n f i g u r a b l e S e r v i c e I m p l . c l a s s ) ;

}

p u b l i c vo id s t o p ( Bund leCon tex t c o n t e x t ) throws E x c e p t i o n {}

}� �Timo Kehrer Service-Varianten und zustandsbehaftete Services auf Basis von OSGi



Zusammenfassung


Konfiguration des Services

Methode des ServiceHelpers:�p u b l i c s t a t i c vo id c o n f i g u r e I n s t a n c e (

Bund leCon tex t c o n t e x t ,C las s <?> i n t e r f a c e C l a s s ,S t r i n g docType ,S t r i n g v a r i a n t ,O b j e c t . . . c o n f i g D a t a )� �

Aufrufbeispiel:�S e r v i c e H e l p e r . c o n f i g u r e I n s t a n c e (

c o n t e x t ,M y C o n f i g u r a b l e S e r v i c e . c l a s s ,ge tEPackage ( ) . getNsURI ( ) ,"SIMPLE" ,

" c o n f i g . xml " ) ;� �Anschließend steht der Service in konfigurierter Form zurVerfügung.

Die eigentliche Konfiguration erfolgt transparent durch denServiceHelper.




Zusammenfassung


Verwenden des Services

Um einen fertig konfigurierten Service zu verwenden, wird dieserwie alle anderen Services über den ServiceHelperangefordert.

Hier müssen jedoch der Dokumenttyp oder der Dokumenttypund die Variante als Parameter mitgegeben werden, z.B.:

�MyService ms = S e r v i c e H e l p e r . g e t S e r v i c e (

c o n t e x t ,M y C o n f i g u r a b l e S e r v i c e . c l a s s ,eObj . e C l a s s ( ) . ge tEPackage ( ) . getNsURI ( ) ,"SIMPLE" ) ;� �




Zusammenfassung










Zusammenfassung


Konfigurierbare und zustandsbehaftete Services




Zusammenfassung

Zusammenfassung

SiDiff als Werkzeugkasten zum Bau von Differenz- undMischwerkzeugen für ModelleRealisierung einer Service-orientierten Architektur auf Basis vonOSGi

Umsetzung der SiDiff-spezifischen Anforderungen durch eine aufdem OSGi Standard aufbauende Service-Schicht

Kapselung des OSGi-FrameworksUnterstützung von zustandsbehafteten ServicesUnterstützung von Service-VariantenUnterstützung der Kombination beider Service-Arten




Zusammenfassung

Vielen Dank für Ihre Aufmerksamkeit

Fragen?

www.sidiff.org


www.sidiff.org

Realisierung von Service-Varianten und zustandsbehafteten Services aus Basis von OSGi

Documents

Transcript of Realisierung von Service-Varianten und zustandsbehafteten Services aus Basis von OSGi