ekkes corner - ekkes ecke
ekkes corner - ekkes ecke

HowTo Build an OSGI Enterprise Server: EJB3 Container
Freitag, 14. November 2008
Dieser Teil der Blog - Serie „HowTo build an OSGI Enterprise Server“ beschäftigt sich mit dem „EJB3 Container“, der von EasyBeans verwaltet wird. EasyBeans arbeitet standardmässig mit Felix - diese Blog-Serie beschreibt den Einsatz unter Eclipse Equinox in Verbindung mit Eclipse Riena.
Damit die OSGI Serveranwendung korrekt startet, müssen ein paar Regeln befolgt werden, die das (automatische) Starten von Bundles, den Einsatz der Start - Level usw. betreffen. Wichtige Informationen dazu finden sich im Kapitel „Server starten“. Eine kurze Übersicht:

Mit dem Server wird ein „Server Agent - Bundle“ automatisch gestartet - dieser Agent enthält einen OSGI Service Tracker, der dafür sorgt, dass der (die) EJB3 Container korrekt initialisiert und gestartet werden und ausserdem die @Remote Business - Interfaces für Riena Remote OSGI Services zur Verfügung stehen.
Ausserdem werden Domain-spezifische „Server Bundles“ gestartet, die dann aktiv werden, wenn ein entsprechender Service vom „Server Agent“ Bundle registriert wurde.
Server Agent und Server - Bundles
In diesem Kapitel über EJB3 Container werden wir das „Server Agent - Bundle“ detailliert betrachten:

Unsere (domain-specific) „Server - Bundles“ und der „Server - Agent“ werden mit dem Default - Start - Level (in unserem Beispiel Level 3) automatisch gestartet.
Die „Server - Bundles“ warten alle, bis ein RienaEasyBeansServerService signalisiert, dass unser Server mit Riena- und EasyBeans - Funktionalität zur Verfügung steht.
Die wichtigsten Abhängigkeiten des „Server - Agent“ - Bundles:

Der „Server - Agent“
•trackt Services von EasyBeans mit dem EasybeansServiceTracker
•registriert Remote - „Business - Interfaces“ für Riena - Remoting
•registriert RienaEasyBeansServerService für die Verfügbarkeit unseres Servers
EasybeansServiceTracker - Filter
Ein OSGI ServiceTracker sollte nur die Services „tracken“, die er benötigt und dazu definieren wir einen Filter der beim Erzeugen des Trackers mit angegeben wird:
(|(objectClass=org.osgi.service.cm.ManagedServiceFactory)(objectClass=org.ow2.easybeans.api.EZBContainer)(objectClass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)(service.pid=*RemoteManagerI*Bean))
Welche Services liefert uns uns nun dieser Filter:
ManagedServiceFactory:
EasyBeans registriert für jede Komponente einen Service vom Typ ManagedServiceFactory:
{org.osgi.service.cm.ManagedServiceFactory}=
{service.pid=org.ow2.easybeans.component.carol.carolcomponent,..
Registered by bundle:
...easyBeans/bundles/easybeans-component-carol_1.1.0-...jar
Bundles using service:
.../org.eclipse.equinox.cm_1.0.0.v20080509-1800.jar
.../org.ekkehard.server.agent_1.0.0.jar
Über diesen Service kann dann festgestellt werden, ob alle EasyBeans Komponenten korrekt initialisiert wurden.
EZBContainer:
Wenn EasyBeans unsere „EJB - Bundles“ und „PersistenceContext - Bundles“ verarbeitet hat, dann wird ein Service vom Typ EZBContainer registriert:
{org.ow2.easybeans.api.EZBContainer}={service.id=103}
Registered by bundle: .../org.ekkehard.foo.datamanager.bean_1.0.0.jar
Bundles using service:
.../easybeans-core_1.1.0-M3-SNAPSHOT.jar
.../org.ekkehard.server.agent_1.0.0.jar
Wenn dieser Service getrackt wird, wissen wir, dass EasyBeans einen EJB3Container für unser Bundle erzeugt hat und - bei den „PersistenceContext - Bundles“ wissen wir, dass Hibernate das Mapping und Binding durchgeführt hat.
JDBCPoolComponent:
EasyBeans JDBCPoolComponent registriert jeweils nach Initialisierung einer DataSource einen Service vom Typ JDBCPoolComponent:
{org.ow2.easybeans.component.api.EZBComponent,
org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent}=
{... jndiName="foo_data_source_hsql"....
Über das Property jndiName können wir testen, ob unsere DataSource zur Verfügung steht.
service.pid:
Wir filtern Services mit einer service.pid, die unserem Muster für Remote - Business - Interfaces entspricht: „*RemoteManagerI*Bean“.
Die Services, die wir damit beim Tracking erhalten, sind Services vom Typ ManagedService. Wir prüfen dann noch zusätzlich, ob Properties von EasyBeans gesetzt wurden. Wenn ja, dann wissen wir, dass es sich um einen Service handelt, den EasyBeans für eines unserer @Remote - „Business - Interfaces“ erstellt hat.

Dann können wir dieses @Remote - „Business - Interface“ für Riena Remoting registrieren, damit es als Riena Published Endpoint den Rich Clients zur Verfügung steht.
Dies ist auch der Grund, warum wir Dependencies vom „Server - Agent - Bundle“ zu den „Business - Interface - Bundles“ haben - wer also keine Riena Endpoints benötigt, kann diese Dependencies ignorieren.
Der RienaEasyBeansServerService
Unser „Server - Agent - Bundle“ stellt nach erfolgreichem Tracking einen RienaEasyBeansServerService als OSGI Service zur Verfügung. Da dieser Service auch als Riena Remote Endpoint registriert wird, können die „Rich Client - Bundles“ ebenso wie die „Server - Bundles“ feststellen, ob der Server für ihre Domain live und ready-to-go ist.
Wie stellt der „Server - Agent“ nun fest, dass alles erfolgreich war ?
•Alle EasyBeans Komponenten sind initialisiert
•Alle DataSources stehen zur Verfügung
•Alle EJB Container stehen zur Verfügung
Bei der Reihenfolge der Abfragen sind noch einige Hürden zu nehmen - aber das ist ein anderes Thema im nächsten Blogeintrag.
Den Index der Blogserie finden Sie hier - Diskussionen bitte in der englischen Ausgabe.