blog of itemis l.e.

Wer ein neues modellbasiertes Projekt anfängt, steht u.a. vor folgenden Aufgaben:

1. Referenzimplementierung inkl. Systemarchitektur realisieren
2. Modellierungssprache ausdenken
3. Codeschablone schreiben
4. manuellen Code ergänzen

Wer das öfters macht kommt schnell auf die Idee, vielleicht aus dem letzten Projekt die Modellierungssprache oder Teile der Codeschablone o.ä. wiederzuverwenden. Konsequent weitergedacht macht es so natürlich Sinn, vielleicht genau für die Wiederverwendung auf Werkzeugebene ein eigenes Framework aufzubauen. Dieses hätte den Vorteil eine erprobte Systemarchitektur zu generieren und jede Menge geteste Codeschablonen zu beinhalten.

Und genau das ist die Fornax Plattform. Dort gibt es verschiedene Cartridges, u.a. auch Sculptor. Just von diesem wurde Anfang dieser Woche die Version 1.5.0 veröffentlicht.

Konkret benutzen wir Sculptor momentan in einem Projekt, in dem wir das JEE-Backend, ablaufend im JBoss, zu großen Teilen generieren. Das Frontend basiert auf eclipse RAP und läuft im OSGi-Container equinox. Dort haben wir die Infrastruktur generiert und die UI noch teilweise per Hand ergänzt. Die Kommunikation zwischen beiden Containern wurde auf Basis Spring Dynamic Modules und JEE Stateless Session Beans generiert. Automatisch gebaut wird das Ganze natürlich mit Apache Maven.

Wer also gern mal das typische Helloworld Projekt modellbasiert realisieren möchte, ist eingeladen einfach Sculptor auszuprobieren. Das gesamte Framework ist Open Source und lebt natürlich vom Mitmachen.

/Steffen…

Im klassischen Entwicklungsumfeld hat man neben log4j, commons-logging und slf4j einge ganze Handvoll Frameworks, um Logging zu realisieren. OSGi definiert nun ebenfalls einen eigenen LogService und mit Pax-Logging existiert ein Bundle, welches zB. log4j als OSGi LogService (org.osgi.service.log) zur Verfügung stellt.

Integriert man in seiner Anwendung verschiedene Frameworks wie zB. Hibernate hat man sehr schnell unterschiedlichste Logging-Frameworks in seiner Anwendung. Noch unübersichtlicher wird das Ganze, da bei OSGi jedes Bundle eine spezielle Version eines Logging-Frameworks benötigen kann.

Ekkehard Gentz hat in seinem (derzeit) 3-teiligen Blog

Logging in OSGi Enterprise Anwendungen – Teil 1

Logging in OSGi Enterprise Anwendungen – Teil 2

Logging in OSGi Enterprise Anwendungen – Teil 3

die verschiedenen Logging-Strategien im OSGi-Umfeld beleuchtet und mögliche Probleme durch Bundle-Abhängigkeiten untersucht. Interessant auch der Ansatz, die Logging-Ausgaben der verschiedenen klassischen und OSGi-Logging-Frameworks aufzusammeln und über einen gemeinsamen Logging-Mechanismus auszugeben.

Im Vorfeld des OSGi Community Events der OSGi Alliance am 10. und 11. Juni in Berlin fand am Nachmittag des 9. Juni das erste Treffen des deutschsprachigen OSGi User Forum in den Deutsche Telekom Laboratories in Berlin statt. Etwa 50 Teilnehmer, sowohl aus dem Enterprise sowie Embedded Bereich, nahmen daran teil. Als Anwendungsbeispiel der OSGi Plattform wurde das vom BMWi teilfinanzierte SerCHo Projekt vorgestellt. Durch das User Forum soll vor allem die Verbreitung der OSGi Serviceplattform im deutschsprachigen Raum gefördert werden.

In einer losen Gesprächsrunde war es interessant zu hören, mit welchen Motivationen und Erwartungen die einzelnen Teilnehmer zur Veranstaltung gekommen sind. Besonders spannend wird dabei in Zukunft die Verbindung des modellbasierten Ansatzes mit dem OSGi Framework sein.

Wir wollen demnächst versuchen, ein Testprojekt unter Verwendung der OSGi Plattform zu realisieren.