Tino Sperlich

Kategorien
Buch
Film
Foto
Gesellschaft
HH TTT
Links
Musik
Reise
Schon-immer-mal
Software + Java

OSG and i and me

Im East Hotel gibt es einen Vortrag von Peter Kriens zu OSGi: Open Services Gateway initative - ursprünglich gedacht, um in der Heimautomatisierung einen Standard zu entwerfen. Peter ist ein guter Referent, bunte scharfe Fotos und wenig Text, einige Animationen.

Anfang:

1998 Java Embedded Server auf der eBox ("Does anyone know the embedded server?") im Auftrag von Ericsson: Die Idee war, eine von zentraler Stelle verwaltete Box zu haben, die zu Hause Annehmlichkeiten verbreitet. Die Idee war ca. 10 Jahre zu früh, heute ist im Zuge von DSL und NAS und Mediaserver zu Hause ein neuer Anlauf möglich.

 

Stichpunkte:

OSGi is adding thing onto Java. Java is not a controlled environment; there are no metadata or service descriptions of an application -> therefore the execution environment is build. It tells you instantly if an installed app will run or not by figuring out the mandatory and optional dependencies. It's a "Predict error instead of discover the error" approach.

 

(c)

Modules manage the classpath as bundles. Lifecycle accounts for the dynamic in a system and provide a standard API for start/stop/install/uninstall and eventing of those phases. Problems should be solve in services not modules. In structured programming manipulation of data from different functions simplified a lot of things, but we totally forgot about coupling: Look at the java dependencies of a mid-size project - it's almost like a Jackson Pollock painting (rumour has it he was the first OO programmer :-)) Coupling is today tried to solve using factories, IoC frameworks but the main evil is - the java classpath  

It creates one big linear namespace where all kinds of wired things occur:
Example of split packages:

Class MyApp (requires de.package lib version >=1.1)
import de.package1.A;
import de.package1.B;

The classpath contains de.package1 in version 1.0 with only Class A and de.package1 in version 1.2 with Class B. What happens is that Class A is taken from version 1.0 and Class B from Version 1.2 - no problem at classloading time, but may at execution time...

OSGi is not designed as a replacement for the classpath; works though. It rather is designed for dynamics in a system - service are available or not at any time, the go up and down and have to be managed. In Win95 and further on you go: start, read config, change config, reboot - that's the lazy programmer's approach. With OSGi you'll receive events about changes, they effect immediately. Consider dynamic a first class cititzen in your design!

Spring and OSGi dont overlap much - rather have the spring guys been pushing for bundles and provide their bundle repository and a spring application platform:

Adrian Colyer: it bootstraps enterprise application development into the world of OSGi by making standard OSGi bundles with standard OSGi semantics work with existing enterprise application libraries. The OSGi support is one of the features we're most excited about, but the SpringSource Application Platform is also an excellent server platform for deploying standard war files.