Das Dokument behandelt OSGi (Open Service Gateway Initiative) und dessen Einsatz zur Lösung von Problemen klassischer Java und JEE-Anwendungen sowie bei Portal-Anwendungen. Es werden Herausforderungen wie ungewollte Abhängigkeiten, fehlende explizite Definitionen von Abhängigkeiten und Versionskonflikte aufgeführt sowie Lösungen durch modulare Architektur und die Verwendung von Bundles vorgeschlagen. Zudem wird ein Beispiel für eine Anwendung, die Trinkgeldkasse, erwähnt.

1. inovex BrownBag OSGi (+ Spring MVC) Pforzheim, 21. September 2009 Sandro Böhme [email_address] Eingetütet von:

2. Agenda Was ist OSGi? Probleme klassischer Java Anwendungen Probleme in JEE Anwendungen Wiederverwendbare Module in JEE Anwendungen Probleme bei Portal Anwendungen Lösungen von OSGi Beispiel mit Spring DM und Spring MVC (ggf. Abgrenzungen) 25. August 2009 Copyright: inovex GmbH, 2009

3. OSGi (Open Service Gateway initiative) Laufzeitumgebung Bundle Ein normales jar, das im META-INF/MANIFEST.MF weitere Infos enthält. Ein Singleton. In einer Version kann es nur einmal existieren. Service Ein beliebiges Java Interface. Kann instantiiert werden. Gehört zu einem Bundle ...es gibt noch mehr... Was ist OSGi? 25. August 2009 Copyright: inovex GmbH, 2009

4. Deployment Alles oder Nichts Öffentliche API Alle public Klassen von allen Jars sind sichtbar Gefahr ungewollter Abhängigkeiten Definition der Abhängigkeiten Es gibt keine explizite Definition ausser mit Maven. Gefahr für ClassNotFoundException, NoClassDefFoundError,... Zwei Versionen des selben jar's nicht möglich Probleme klassischer Java Anwendungen 25. August 2009 Copyright: inovex GmbH, 2009

5. Probleme in JEE Anwendungen 25. August 2009 Copyright: inovex GmbH, 2009

6. Probleme in JEE Anwendungen Deployment WAR's, EAR's können unabhängig deployed werden Öffentliche API Sichtbarkeit entsprechend der Ebene im Baum Sichtbarkeit entsprechend Descriptor Definition der Abhängigkeiten Nicht komplett explizit. Teilweise in Deployment Descriptoren. Man kann die Abhängigkeiten zwischen Jars zur Entwicklungszeit nicht eindeutig auflösen. Doku und testen Gefahr für ClassNotFoundException, NoClassDefFoundError,... 25. August 2009 Copyright: inovex GmbH, 2009

7. Wiederverwendbare Module in JEE Anwendungen Lösung 1 Jars in den Server ClassPath legen -> Probleme: Nicht mehr unabhängig deploybar Scope kann zu groß sein Versionskonflikte mit anderen jars Lösung 2 Jars tiefer in die Hierarchie legen -->Problem: Verbraucht mehr PermGen Space 25. August 2009 Copyright: inovex GmbH, 2009

8. Probleme bei Portal Anwendungen Ziel Austauschbare Schnipsel einer Webseite Portlet wird oft als WAR deployed Problem Unabhängige Frameworks pro WAR erzeugen redundante jars und damit zu viel PermGen Space Lösungen Pures JSTL verwenden Ein Framework für alle Portlets Bei Zeitgeist: meistens Struts Portlets Führt aber eigentlich die Portlet-Idee ad absurdum 25. August 2009 Copyright: inovex GmbH, 2009

9. Keine redundanten jars nötig Abhängigkeiten sind graphbasiert Abhängigkeiten berücksichtigen Versionen der jars/bundles Explizite Definition der öffentlichen API Ein Bundle (jar) gibt im manifest File die exportierten Packages an Andere Packages sind nicht sichtbar Explizite Definition der Abhängigkeiten Im Manifest File werden die importierten Packages inkl. Version angegeben Zur Entwicklungszeit gibt es Fehlermeldungen, wenn andere Packages verwendet werden Austauschbarkeit zur Laufzeit Bundles (und dessen Services) können zur Laufzeit hinzugefügt, entfernt, oder aktualisiert werden. (das macht das System aber auch komplexer) Lösungen mit OSGi 25. August 2009 Copyright: inovex GmbH, 2009

10. Beispielanwendung: Trinkgeldkasse 25. August 2009 Copyright: inovex GmbH, 2009

11. Beispielanwendung: Trinkgeldkasse 25. August 2009 Copyright: inovex GmbH, 2009

12. 25. August 2009 Copyright: inovex GmbH, 2009 Vielen Dank für eure Aufmerksamkeit!