Beideskönner. Wie das Gemini Blueprint Projekt Spring und OSGi miteinander sprechen lässt

Beideskönner. Wie das Gemini Blueprint Projekt Spring und OSGi miteinander sprechen lässt

Es könnte doch eigentlich alles so schön sein.

In der Theorie lernen wir von Programmierers Kindesalter an, wie moderne Architekturen aussehen, wie moderne objekt- und vor allem service-orientierte Konzepte funktionieren. Dass über Bausteingrenzen hinweg munter und verteilt kommuniziert wird, dass ein hoher Wiederverwendungswert einzelner Bausteine zum schnellen voranschreiten in der Projekt-Entwicklung führt und dass wir das Rad nur noch selten neu erfinden müssen. Modernes Programmieren gleicht mehr dem zusammensetzen von Bausteinen zur Entwicklung einer Lösung statt dem klassischen Entwickeln von Bausteinen selbst.

Als Spring noch das allgemein gängige Handwerkszeug war, um Bausteine von Software Architekturen elegant zu entkoppeln, gab es keine Sprachbarriere. Spring-Beans konnten sich wunderbar untereinander und mit Hibernate unterhalten, mit gut zusammengestellten Konfigurationsdateien waren schnell große Projekte aufgesetzt und zusammengepuzzelt.

Nun stellt seit einigen Jahren OSGi die spring’sche Vormachtstellung in Frage bzw. greift unterstützend und maßgebend in neuere Systemarchitekturen ein. Daher scheint es nur folgerichtig, eine verständliche Antwort auf die Frage „Was ist OSGi?“ zu suchen und zu untersuchen inwiefern OSGi mit Spring kombiniert werden kann.

Also, was ist das nun, OSGi und warum gilt es überhaupt darüber nachzudenken zukünftige Systeme in ein OSGi Umfeld zu integrieren, wenn Spring doch unsere Probleme bisher ganz vorzüglich lösen konnte?

Read More