Der Begriff SOA ist sehr geläufig. Dabei handelt es sich lax ausgedrückt um eine verteilte, lose gekoppelte heterogene Struktur von Applikationen die oftmals mittels einer Middleware (z.B. eines ESB) zusammenhängen. Jede dieser Applikationen bieten dabei der SOA ihre Services an.
Nimmt man eine Lupe zur Hand und schaut sich eine Applikation dieser SOA genauer an könnte man möglicherweise eine Applikation ausfindig machen, die auf OSGi aufgebaut ist und dedizierte Services der SOA anbietet.
Die Architektur einer solchen OSGi Anwendung hat gewisse Ähnlichkeit mit einer echten SOA. Alle OSGi Bundles sind autarke Softwarekomponenten die Services veräußern und der OSGi Runtime und damit anderen Bundles anbieten. Alle Komponenten sind dabei ebenso lose gekoppelt und können während des Betriebs aktiviert bzw. deaktiviert werden ohne größeren Schaden auf andere Komponenten auszuüben.
Die oben erwähnte Middleware ist zu vergleichen mit der OSGi Runtime. Ein vernünftiger OSGi Server wie der SpringSource dmServer bietet eine solide OSGi Laufzeitumgebung die keine Wünsche offen lässt.
Zum Thema Verteilung (wenn dies wirklich ein Thema sein sollte): "1st law of istribution is, don't distribute, if you don't and won't have to" (Martin Fowler).
Sollte man dennoch in die Verlegenheit kommen OSGi Services verteilen zu müssen, wäre vielleicht das Projekt R-OSGi der ETH Zürich ganz interessant.
µSOA!
Alles in allem könnte man also eine OSGi Applikation inkl. OSGi Runtime als eine µSOA bezeichnen.
Keine Kommentare:
Kommentar veröffentlichen