OSGI Bundles - The Big Picture

Nachdem ich nun lange genug gebastelt habe und einige Umstrukturierungen vornahm, möchte ich mal so zwischendurch ein Overview der verschiedenen OSGi Bundles aufzeigen. OSGi Service Referenzen sind rot markiert und OSGi Package Imports grün. Lediglich der Flex Client nimmt ein zweites Flex Modul während des Kompilierens hinzu (akzeptabel)



Der Flex Client nutzt also die OSGi Service Registry um Services zu finden, die direkte Implementierung übernimmt hier ein anderes Bundle (...spring). Diese Trennung rührt daher, da es in früherer Zeit eine zweite Service Implementierung auf Basis von EJB gab.

Die Service Implementierung nutzt ein Bundle der Integrationsschicht (war dies nicht was mit DAO!?), dies wird ebenfalls über die OSGi Service Registry aufgelöst.

Implementiert wird dieses "DAO" Interface Bundle durch ein Bundle welches JPA nutzt (...integration.jpa). Die DAO Implementierung muss natürlich die JPA Entity Klassen kennen (in common.domain und tms.domain). Der Übersicht wegen sei hier auf die Referenzierung von Services und Client auf diese Bundles verzichtet.

Das Bundle ...integration.jpa ist in sofern interessant, da hier der PersistenceContext (sprich:EntityManagerFactory) erzeugt wird. Es müssen also die Bundles mit den Entity Klassen bekannt sein. Ausserdem braucht die Initialisierung des EM auch eine DataSource (Bundle:infrastructure.postgres) und einen JPA Provider (integration.eclipselink). Diese sind in zwei separate Bundles ausgelagert um sie austauschbar zu halten, JPA kann EclipseLink, Hibernate... sein wobei die DataSource die dahinterliegende DB verstecken sollte.

Was auf diesem Bild nicht eingezeichnet ist, das es nicht in diesem Scope liegt, ist ein Modul der Domain Objekte in ActionScript. Diese Klassen werden aus den Java Domain Objekten generiert und dienen dem Flex Client, haben also keinen direkten Bezug zu OSGi (daher Modul und nicht Bundle).