service components and distribution with osgi seminar: multimedia- und internetsysteme paul hübner...

Service components and distribution with OSGi Seminar: Multimedia- und Internetsysteme

Paul Hübner | 10.01.2011

Bildquellen : [1] http://www.osgi.org/wiki/uploads/Main/logo1.jpg[2] http://www.flickr.com/photos/jurvetson/916142

Multimedia- und Internetsysteme | Service components and distribution with OSGiSeite 2

Inhalt

OSGi Einführung

Service Component Models

OSGi für Verteilte Systeme

Zusammenfassung


OSGi Architektur

Quelle: OSGi 4.2 Core Spezifikation, Seite 1-332, Abbildung 1


OSGi Bundle Lebenszyklus

Quelle: OSGi 4.2 Core Spezifikation, Seite 97-332, Abbildung 4.28


OSGi Servicelayer , SOA Pattern : Publish-Find-Bind

Service Registry

Service Provider

Service Requestor

Publish Find

Bind


OSGi Serviceorientierung

• Service Implementierung = POJO

• Beschrieben durch Java Interface

• Unabhängig von der Implementierung

• Veröffentlichen von Bundle Funktionalität

• Zentrale Service Registry durch OSGi

Framework


Inhalt

OSGi Einführung



Zusammenfassung


Service Orientierte Entwicklung mit OSGi

• Probleme:

• Kopplung an das OSGi Framework

Wiederverwendbarkeit

• Komplexe Implementierung eines nicht Anwendungsspezifischen Aspektes

Einfachheit , Fehleranfälligkeit, …


Lösung : Service Component Models (SCM)

• Service Component Model:– Service Vertrag zwischen OSGi Bundles

• Was muss ein Service Component Model leisten:– Keine OSGi APIs im Quellcode der eigenen Anwendung

• d.h. auch keine Activator Klasse

– Definition von Services nicht im Quellcode sondern:

• In XML Dateien oder mit Java Annotationen

• Service = Java Interface, Service Impl. = Java Bean

– Service Referenzen werden durch SCM verwaltet

• Einschließlich der Reaktionsmöglichkeiten auf Service Dynamik


Service Component Models - Übersicht

• Declarative Services Specification

• Blueprint Container Specification

(Spring DM)

• Apache iPOJO (inject POJO)

• Google Guice & Peaberry


Declarative Services (DS)

• Seit Version 4.1 Teil der OSGi Compendium Spec. • XML Definition für Services & Service Referenzen • Definiert durch Service-Component Manifest Eintrag

– Default Ordner im Bundle: OSGI-INF/*.xml• Bestandteile:

Service Componet Runtime

OSGi Framework Instanz

Service Referencen

Bundle

Service Definitionen

Bundle

Service Vertrag

Bundle

…consume

provide

Implementiert als OSGi Bundle

Bundels werden um Service XML Definition erweitert


Blueprint Container (Spring DM)

• Seit Version 4.2 Teil der OSGi Compendium Spec. • Entstanden aus Spring Dynamic Modules (V. 2.0)• Definiert durch Bundle-Blueprint Manifest Eintrag

– Default Ordner im Bundle: OSGI-INF/blueprint/

Blueprint Container

Blueprint Bundlecomponent instances …

BlueprintXML

service reference

service

Blueprint Container Listener

Blueprint ExtenderBlueprint Container Impl

Blueprint Bundle…

Implementiert in 3 OSGi Bundles, weitere Bundles für Spring erforderlich!


Apache iPOJO (inject POJO)

• Vorreiter in Sachen OSGi SCM • Beeinflusste Declarative Services & Blueprint Container

• Ähnlich Blueprint (Spring DM):• Trennung von Service Impl. & SCM Aspekten

• Apache Projekt, nicht im OSGi StandardSchnellere Entwicklungs- und Release-Zyklen

• Unterschiede:• Konfiguration auch über ConfigureAdmin Service

• Verbindung zwischen Metadaten und POJO zur Build-Zeit


Google Guice & Peaberry

• Google Guice als Dependency Injection Framework• Guice Basierend auf Java Annotationen• Peaberry ist eine Erweiterung für Guice• Ermöglicht mit speziellen Annotation :

– Das erstellen von OSGi Service Objekten

– Das referenzieren von OSGi Services

– Das interagieren mit dem Service/ Bundle Lebenszyklus, d.h. umgang mit OSGi Service Dynamic


Service Component Models Review

Anzahl Bundles

Einsatz-bereich

Release-zyklus

Version

Declarative Services

1 Eclipse Plattfom Integration

OSGi Spez.

1.1

Blueprint Container

3 (13) Enterprise OSGi Spez.

1.0 (2.0)

Apache iPOJO

1 Performance kurz 1.6.8


1 (2) Java Annotation Verfechter

? 1.1.1


Inhalt

OSGi Einführung



Zusammenfassung


OSGi für Verteilte Systeme: Anforderungen

Aus der SOA im kleinen wird eine „echte“ SOA– Betreiben von OSGi Bundles ohne Anpassung

– Veröffentlichen & Nutzen von Service

Verteiltes OSGi Famework

VerteiltesSystem

Peers


Arten der Verteilung (1): Bundle Verteilung

• Bundles zur Serviceumsetzung werden Verteilt• Keine Netzwerk Kommunikation bei Service Aufruf

Service Bundle

Service BundleKopie

Netz-werk

Bundle

Verteiltes OSGi System

Peer 1 Peer 2

Bundle Daten Austausch



Arten der Verteilung (2): Automatische Proxy Generierung

• Bei 1. Service Aufruf wird ein Proxy Bundle erzeugt• Netzwerk Kommunikation bei Service Aufruf

Peer 1

Service Bundle

ProxyService Bundle

Netz-werk

Nachrichtenaustausch

Peer 2


R-OSGi, Architektur

Distributed R-OSGi:- Durch Verwendung von jSLP (Service Location Protocol)

• binäres Java Bytecode basiertes Kommunikationsprotokoll- Automatic Proxy Bundle Generation- Distributed Service Registry

R-OSGi R-OSGi R-OSGi

Peer 1 Peer 2 Peer n…


R-OSGiBundle

Lokales OSGiFramework


Remote Services & Distributed OSGi, Architektur

Lokale OSGi Frameworks

Distributed OSGi

ServiceConsumer Impl.

ServiceProducerImpl.

Distribution Provider Impl.

to endpoint endpoint

import service

exportservice

service.exported.interface

service.imported

Quelle: OSGi 4.2 Compemdium Spezifikation, Seite 5-850, Abbildung 13.1, Überarbeitet


Remote Services - Distribution Provider

• Kern von Remote Services• Abstrakte Impl. Unabhängige

Spezifikation• Referenz Impl. : Apache CXF• Basiert auf WS Standards:

– SOAP & WSDL, JAX-WS &-RS, Spring Integration, …


OSGi als Middleware Plattform

• Lokales OSGi Framework

– Standardisiertes Komponenten Laufzeitsystem

– Service Plattform, einschließlich Standard Services (http, logging, …)

• Distributed OSGi (R-OSGi, Remote Services, …)

– Schafft Ortstransparenz

– Verteilte Service Registry

– Verteilt lokale Komponenten

Eignung Verteilter OSGi Systeme als Middleware Plattform


Inhalt

OSGi Einführung



Zusammenfassung


Evaluation: Service Component Models & Remoting Konzepte

R-OSGi Remote Services(Apache CXF)

Declarative Services + +

Blueprint Container + +

Apache iPOJO + +


+ -


Zusammenfassung

• OSGi unterstützt Serviceorientierung• OSGi Entwicklung „ohne“ OSGi durch

Service Component Models– Declarative Services, Blueprint, iPOJO, Peaberry

• OSGi als Middleware Plattform für Verteilte Systeme– R-OSGi: einfach & performant Embedded

– Remote Services: komplex, Anbindung an Enterprise Welt, SOA


Ende

• Vielen Dank für die Aufmerksamkeit – Fragen ?

service components and distribution with osgi seminar: multimedia- und internetsysteme paul hübner...

Documents

osgi service objekten

osgi seite

osgi services

osgi compendium

osgi seminar

osgi servicelayer

osgi architektur quelle

keine osgi apis im quellcode