%0 Journal Article %1 Zoerne2008 %A Zörner, Stefan %D 2008 %J Java Magazin %K architecture design osgi zörner %P 52 - 56 %T Zukunftsentwürfe - Applikationsdesign im Zeitalter von OSGi %V 8 %X Sehr guter Artikel welcher die Fragen beantwortet die man sich stellt, wenn man seine eigene Applikation OSGi konform aufsetzen möchte. Es werden Hinweise gegeben, was man tun soll und was nicht. Erfahrungsberichte zu den Hinweisen können noch nicht umfassend geliefert werden, da Erfahrungen im Applikationsserverumfeld erst beginnen. Die bisherigen Erfahrungen beruhen auf Projekten wie Eclipse, Appache OSGi konforme Projekte wie http://felix.apache.org/site/index.html und andere. Grundaussage des Artikels ist: Baue alles wie bisher, erstelle ein sehr gutes Design und entscheide im Rahmen von OSGi welche öffentlichen Methoden published werden und welche nicht. Die Grunlagen guter Softwareentwicklung sollen auf keinen Fall weggeworfen werden und erst nach deren Sicherstellung soll OSGi ins Spiel kommen. Bei OSGi geht es vor allem darum Bundles als Strukturierung oberhalb von Packages zu nutzen und nach dem Design diese Bundles für das Deployment zu schneiden. Für verschiedene Umgebungen kann es durchaus erforderlich sein Bundels verschieden zu schneiden. Bundle = Komponente -> nein -> sonst wird eine zu enge Kopplung erzeugt Bundles sind auch JAR Files OSGi spezifische Klassen (Aktivatoren, ...) in extra Packages auslagern Einfach bauen wie bisher und dann die JARs mit zusätzlichen OSGi Infos bestücken. OSGi hat zwei Grundkonzepte: 1) Service -> Implementierung eines Interfaces (Services) und Bereitstellung des Services im Bundle Vorteil: Service kann von anderen Bundles dynamisch zur Laufzeit genutzt werden (per Registrierung) Nachteil: Service wird immer gestartet unabhängig ob ihn ein Bundle nutzt oder nicht 2) Extension Points -> Mechanismus selbst implementieren oder aus anderen Projekten (Equinox) nachnutzen. Vorteil: Bundle Aktivierung erfolgt nur bei Bedarf Nachteil: komplexer zu implementieren, mehr Abhängigkeiten Fazit: OSGi erweitert Java um Ausdrucksmittel für gewollte und unerwünschte Abhängigkeiten und die Erweiterbarkeit zur Laufzeit. Der Entwurf einer anwendung unter Verwendung von OSGi zwingt Sie, bei der Umsetzung Dinge explizit zu machen (z.B. das Bilden von Modulen, das Deklarieren von Abhängigkeiten), die für ein gutes Design ohnehin nerlässlich sind.

@article{Zoerne2008, abstract = {Sehr guter Artikel welcher die Fragen beantwortet die man sich stellt, wenn man seine eigene Applikation OSGi konform aufsetzen möchte. Es werden Hinweise gegeben, was man tun soll und was nicht. Erfahrungsberichte zu den Hinweisen können noch nicht umfassend geliefert werden, da Erfahrungen im Applikationsserverumfeld erst beginnen. Die bisherigen Erfahrungen beruhen auf Projekten wie Eclipse, Appache OSGi konforme Projekte wie http://felix.apache.org/site/index.html und andere. Grundaussage des Artikels ist: Baue alles wie bisher, erstelle ein sehr gutes Design und entscheide im Rahmen von OSGi welche öffentlichen Methoden published werden und welche nicht. Die Grunlagen guter Softwareentwicklung sollen auf keinen Fall weggeworfen werden und erst nach deren Sicherstellung soll OSGi ins Spiel kommen. Bei OSGi geht es vor allem darum Bundles als Strukturierung oberhalb von Packages zu nutzen und nach dem Design diese Bundles für das Deployment zu schneiden. Für verschiedene Umgebungen kann es durchaus erforderlich sein Bundels verschieden zu schneiden. Bundle = Komponente -> nein -> sonst wird eine zu enge Kopplung erzeugt Bundles sind auch JAR Files OSGi spezifische Klassen (Aktivatoren, ...) in extra Packages auslagern Einfach bauen wie bisher und dann die JARs mit zusätzlichen OSGi Infos bestücken. OSGi hat zwei Grundkonzepte: 1) Service -> Implementierung eines Interfaces (Services) und Bereitstellung des Services im Bundle Vorteil: Service kann von anderen Bundles dynamisch zur Laufzeit genutzt werden (per Registrierung) Nachteil: Service wird immer gestartet unabhängig ob ihn ein Bundle nutzt oder nicht 2) Extension Points -> Mechanismus selbst implementieren oder aus anderen Projekten (Equinox) nachnutzen. Vorteil: Bundle Aktivierung erfolgt nur bei Bedarf Nachteil: komplexer zu implementieren, mehr Abhängigkeiten Fazit: OSGi erweitert Java um Ausdrucksmittel für gewollte und unerwünschte Abhängigkeiten und die Erweiterbarkeit zur Laufzeit. Der Entwurf einer anwendung unter Verwendung von OSGi zwingt Sie, bei der Umsetzung Dinge explizit zu machen (z.B. das Bilden von Modulen, das Deklarieren von Abhängigkeiten), die für ein gutes Design ohnehin nerlässlich sind.}, added-at = {2010-09-12T18:14:42.000+0200}, author = {Zörner, Stefan}, biburl = {https://www.bibsonomy.org/bibtex/2dfa7f94742aa11e6dab11e68b634b2b9/funthomas424242}, interhash = {7f3e3677ee664cdf2b6315c714ca11ab}, intrahash = {dfa7f94742aa11e6dab11e68b634b2b9}, journal = {Java Magazin}, keywords = {architecture design osgi zörner}, pages = {52 - 56}, timestamp = {2012-10-14T13:00:08.000+0200}, title = {Zukunftsentwürfe - Applikationsdesign im Zeitalter von OSGi}, volume = 8, year = 2008 }