eclipse... RCP... Riena... OSGI... Equinox... MDSD... oaw... uml... Business processes... business rules...

New Ways Around Generation GAP Pattern - VideoCast

Sun, 10 May 2009 15:55:26 +0200

Um die etwas komplizierte Thematik des Generation Gap Patterns, sowie der VetoRedirectStrategie im oAW Workflow etwas verständlicher darzustellen, gibt es jetzt ergänzend zu meinem Blogeintrag „New Ways around Generation Gap Pattern“ das ganze als VideoCast - have Fun !

Da ich nach der Veröffentlichung meiner ersten Filmchen erfahren habe, dass es ganz unterschiedliche Wünsche (und Kompatibilitätsprobleme) gibt, veröffentliche ich in verschiedenen Formaten und Plätzen - da kann sich jeder das passende raussuchen:

• http://vimeo.com/ekkescorner als HD Film
• http://ekkes-corner-tv.org als QuickTime direkt aus dem Browser
• http://www.slideshare.net/ekkescorner als Slides (ohne Ton und Animation)
• iTunes: als VideoCast für iPod/iPhone bzw. AppleTV/Desktop (einfach nach „ekkes-corner“ suchen)

Viel Spass - Diskussionen bitte wie üblich im englischsprachigen Blog.

ekke

New Ways Around Generation GAP Pattern

Tue, 5 May 2009 17:05:16 +0200

ModelDrivenSoftwareDevelopment - Best Practices

Es gibt ein paar Grundsätze für MDSD Projekte, die unstrittig sind:

• generierter Code muss sauber getrennt sein von manuell erstelltem Code
• generierter Code sollte nicht in ein VersionsKontrollSystem (CVS, SVN, GiT) eingecheckt werden

Innerhalb eines MDSD (ModelDrivenSoftwareDevelopment) Projekts gibt es verschiedene Arten von Code (s.a. Heiko Behrens Artikel)

Manueller Code

Wird nicht generiert, sondern immer manuell erstellt. Es kann sich dabei um Basisklassen handeln oder Code, der in seiner Struktur so selten auftaucht, dass sich eine Generierung nicht lohnt wie zB bei bestimmten Utility- oder Hilfsklassen.

Generierter unveränderter Code

Dieser Code wird generiert und nach der Generierung nie manuell angepasst oder erweitert. Klassen aus diesem Bereich werden immer neu generiert - bestehende Dateien werden beim Generieren überschrieben oder vorher gelöscht.

Generierter veränderbarer Code

Bei dieser Art Code ist es üblich und sinnvoll, dass nach der Generierung manuelle Änderungen oder Erweiterungen erfolgen. Solcher Code wird in ein Verzeichnis generiert wird, in dem bereits vorhandene Dateien erhalten bleiben und neue ggf. hinzugefügt werden. (generate-once)

Generation Gap Pattern

Das Hauptproblem ist: wie gehen wir mit dem Code um, der nach der Generierung geändert werden kann. Hier kommt das Generation Gap Pattern zum Einsatz:

Abstrakte Klassen werden in ein Verzeichnis generiert, das immer wieder überschrieben wird.
Die konkreten Klassen werden nur das erste Mal generiert und können dann geändert werden.

Im praktischen Einsatz ergeben sich einige Probleme mit „Geisterklassen“, wenn konkrete Klassen bei Refactorings und Umbenennungen hängen bleiben. Ausserdem werden alle konkreten Klassen ins VersionsKontrollSystem eingecheckt und man kann nicht auf den ersten Blick erkennen, welche der Dateien wirklich angepasst wurden.

Um das zu verbessern, hat Heiko Behrens als Lösung „Conditional Generation“ vorgestellt, die die generierten und angepassten Dateien trennt. Im oAW Workflow kann eine „Vetostrategie“ angegeben werden: Vor dem Generieren einer Datei wird getestet, ob es diese bereits unter einem anderen Pfad als angepasste Version gibt und wenn ja, dann erfolgt keine neue Generierung.

Das alles ist sehr detailliert beschrieben in Heiko Behrens Artikel „Generation Gap Pattern“. Wer den Artikel noch nicht gelesen hat, sollte das jetzt machen, da mein Blog davon ausgeht, dass die dort beschriebenen Vetostrategien bekannt sind !

Vielen Dank an Heiko Behrens: die oAW „VetoStrategy“ war auch für mich neu, da sie weder im Manual steht noch im Forum erwähnt wurde. Diese Vetostrategy hat mich inspiriert und geholfen, meine Lösungen optimaler zu implementieren als bisher.

Zunächst muss ich gestehen, daß ich ein Problem habe mit dem „Generation Gap Pattern“ als generelles Pattern beim Generieren von Code in MDSD Projekten. Wenn ich als Softwarearchitekt (speziell bei Enterprise Business Applikationen) ein Datenmodell entwerfe, überlege ich sehr sorgfältig die Vererbungshierarchien - insbesondere wenn diese von einem ORM (Object-Relational-Mapper wie Hibernate oder EclipseLink) in Richtung zur Datenbank umgesetzt werden müssen.

Eine ganz simple Vererbung:

Wenn jetzt aufgrund des „Generation Gap Patterns (John Vlissides)“ :

Image from „Generation Gap Pattern“ (c) 1996 John Vlissides

... jede Klasse aufgeteilt wird in eine generierte (meist abstrakte) Klasse und eine zusätzliche (oft das erste Mal generierte) änderbare SubKlasse ...

übliche Umsetzung des generation Gap Patterns in oAW Projekten

... dann „verschmutzt“ das aus meiner Sicht die Vererbungshierarchie. In grossen Projekten führt dies dazu, dass hunderte von Klassen „doppelt“ vorhanden sind nur aus einem technischen Grund: es ist ein modellgetriebenes Projekt.

Ich möchte abstrakte / konkrete Klassen nur dort nutzen, wo sie aufgrund der Softwarearchitektur notwendig sind und Sinn machen, aber nicht, weil ich ein Generatorframework einsetze.

Wie bei jedem Pattern sollte man sich beim Einsatz immer fragen: ist es hier das richtige Pattern oder sollte ich einen anderen Weg gehen ?

Heiko Behrens zeigt auf, wie mit verschiedenen Vetostrategien das Handling der Dateien und Ordner übersichtlicher wird, löst aber nicht das Problem mit dem Aufblähen durch den Verdopplungseffekt.

Protected Areas (geschützte Bereiche)

Also stehen wir wieder vor der Frage, wie wir generierten und manuellen Code trennen können, ohne die Grundsätze von MDSD Projekten zu verletzen.

Es gibt eine Lösung: „ProtectedAreas“ (geschützte Bereiche). Halt halt - bevor es jetzt zum großen Aufschrei kommt, bitte erst weiterlesen - ich setze sie etwas anders ein, als allgemein üblich !

Was sind „Protected Areas“

An allen Stellen im Sourcecode, wo es Änderungen oder Erweiterungen geben darf, werden der Beginn und das Ende über spezielle Kommentarzeilen mit einer „Unique ID“ als geschützte Bereiche gekennzeichnet. Innerhalb dieses geschützten Bereichs wird der Defaultcode generiert.

Wenn der Programmierer etwas ändert, dann „ENABLED“ er den geschützten Bereich und dieser bleibt bei Neugenerierung erhalten. Durch diese „Protected Areas“ bleibt die Klassenstruktur exakt genauso, wie ohne Einsatz eines Generators.

Wie werden „Protected Areas“ allgemein üblich eingesetzt ?

Was ist der Nachteil ?

Jetzt haben die Klassen geschützte Bereiche und werden jedes Mal überschrieben und auch mit ins VersionsKontrollSystem eingecheckt - darunter sind dann auch Klassen, in denen keinerlei Änderungen erfolgt sind. Das aber verletzt die Grundregel, dass reiner generierter Code nicht eingecheckt werden soll.

Ausserdem sieht man auch in diesem Falle nicht, welche Klassen angepasst wurden und welche noch unverändert seit der Generierung sind.

Protected Regions mit VetoRedirectStrategie

So sieht mein Lösungsvorschlag aus

• Als erstes werden die Verzeichnisse „src-gen“ und „veto“ gelöscht
• Der Generator scannt das „src-gen-pr“ Verzeichnis und cached die ENABLED ProtectedAreas
• „normale nur-generierte“ Klassen werden in das „src-gen“ Verzeichnis generiert, ebenso Klassen mit „ProtectedRegions“ ohne Veto
• Im „src-gen-pr“ Verzeichnis befinden sich Klassen mit ENABLED „ProtectedRegions“, die also manuell angepasst wurden.
• Beim Generieren prüft der Generator mit der Vetostrategie, ob es eine Klasse bereits im „src-gen-pr“ Verzeichnis gibt. Wenn ja, dann wird der Ausgabepfad umgelenkt in das „veto“ Verzeichnis und die Datei inklusive der ENABLED ProtectedRegions dorthin geschrieben.
• Am Ende des Generierungslaufs vergleicht der Generator die Dateien im „veto“ Verzeichnis mit den Dateien aus dem „src-gen-pr“ Verzeichnis. Nur wenn diese unterschiedlich sind, werden sie in das „src-gen-pr“ Verzeichnis kopiert. Dadurch erhalten nur geänderte Dateien ein neues „Modification Date“ und werden ins SourceKontrollSystem commited.

Der Workflow

Fazit: Wir erreichen eine saubere Aufteilung zwischen generiertem und manuellem Code, checken nur geänderte Dateien ein und erhalten unsere Vererbungsstruktur.

Problematisch ist sicher, dass der Programmierer nicht vergessen darf, bei Änderungen in „Protected Regions“ diese auch zu aktiveren (ENABLED) und die Datei ins „src-gen-pr“ Verzeichnis zu verschieben, wenn sie dort noch nicht ist.
Wer prüfen möchte, ob ein Entwickler eine protected region ENABLED hat, aber vergessen, die Datei ins „src-gen-pr“ Verzeichnis zu verschieben: einfach „src-gen-pr“ auf vorhandene ENABLED protected regions scannen.
Wer prüfen möchte, ob ein Entwickler vergessen hat, nach Änderungen eine protected region auf ENABLED zu setzen: eine Checksum einbauen in den default code und eine Komponente programmieren, die vorm Generieren eine entsprechende Prüfung durchführt.
Alles ist möglich - muss natürlich unter dem Gesichtspunkt der generierungs - Performance betrachtet werden.
(Tip: bei Fehlern hilft ggf. die lokale History von Eclipse - es gibt aber derzeit noch einen Bug: der Workflow überschreibt den letzten Eintrag der lokalen History, statt einen neuen hinzuzufügen)

Ich trage innerhalb einer „ProtectedRegion“ immer einen auffälligen Kommentartext ein:

Disabled Protected Region:

Enabled Protected Region:

Technische Informationen zur Umsetzung der RedirectVetostrategie

getestet unter:
• Eclipse 3.5M6
• openArchitectureWare 4.3.1 (Wer bereits mit den Eclipse Projekten arbeitet, muss nur den Namensraum anpassen)
• Apache Commons IO 1.4 (SpringSourceEnterpriseBundleRepository - (Eclipse Orbit hat nur Version 1.3.2 von 2007)

Workflow Komponenten

Workflow Komponente Directory Cleaner (oAW Komponente)

outlet.src.dir verweist in diesem Falle auf src-gen,
outlet.veto.pr.dir verweist auf veto.

Workflow Komponente Outlet mit Vetostrategie (Redirect von enabled ProtectedRegions)

Dieses Outlet wendet eine neue Vetostrategie an - ausserdem wurde die Outlet Klasse überschrieben.
outlet.src.dir verweist auf src-gen,
outlet.src.pr.dir auf src-gen-pr und
outlet.veto.pr.dir auf veto.

Workflow Komponente „fileReplacer“ (Ersetzen von Dateien in src-gen-pr ?)

Eine neue Workflow Komponente vergleicht die Dateien im veto Verzeichnis mit den Dateien im src-gen-pr Verzeichnis und ersetzt geänderte.

Ein kurzer Blick in die neuen Klassen und Interfaces

Klasse OutletWithVetoRedirection (erweitert oAW Outlet)

Interface VetoRedirectStrategy (erweitert oAW VetoStrategy)

vetoRedirectSourcePath verweist auf src-gen,
vetoRedirectOutputPath verweist auf veto

Klasse CondGenVetoRedirectStrategy (implementiert VetoRedirectStrategy)

hasVeto gibt immer false zurück, da wir ja kein Veto einlegen wie bei den anderen VetoStrategien die Heiko Behrens beschreibt, sondern nur den Ausgabepfad umlenken in das veto Verzeichnis.

Klasse ReplaceVetoRedirectedFiles (erweitert oAW AbstractWorkflowComponent2)

Apache Commons IO macht es sehr leicht, Datei - Inhalte zu vergleichen und in ein anderes Verzeichnis zu kopieren.
outputFile ist eine Datei in veto,
sourceFile die entsprechende Datei in src-gen-pr

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wichtige Anmerkung:
Inspiriert zu diesem Blog wurde ich durch den excellenten Artikel von Heiko Behrens: „Generation Gap Pattern“.

Heiko Behrens gibt konkrete Lösungsmöglichkeiten im Umgang mit dem „Generation Gap Pattern (John Vlissides)“ beim Einsatz von oAW (openArchitectureWare) Workflow und Xpand / XTend. Bitte meinen Blogeintrag nicht als Alternative sondern ergänzend zu Heikos Vorschlägen betrachten !
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Fazit

Aus meiner Sicht ist die Verwendung von „Protected Areas“ in Verbindung mit „Conditional Generation“ ein in vielen Fällen geeignetes Vorgehen, das die Best Practises im Rahmen von MDSD Projekten nicht verletzt.

Aber wie immer gilt: „Its Your Choice“ - es hängt vom Projekt ab, was Sinn macht.

Heiko Behrens hat mehrere Strategien aufgezeigt - wenn man meine ProtectedRegion Strategie dazu ergänzend betrachtet, gibt es sicher für jeden Anwendungsfall das „passende“.

Es spricht auch nichts dagegen, innerhalb eines grossen Projekts verschiedene (Veto)Strategien beim Generieren von Sourcecode (Artifakten) einzusetzen.

Ich hoffe, ich konnte einige Anregungen geben - Diskussionen bitte im englischsprachigen Blog.

ekke

oAW goes Eclipse Modeling

Tue, 5 May 2009 07:33:29 +0200

oAW goes Eclipse Modeling

oAW wurde in den letzten Monaten in Eclipse Projekte integriert, sodass oAW5.0 das erste Mal über Eclipse 3.5 (Galileo) als Bestandteil vom Eclipse Modeling Projekt ausgeliefert werden soll:

• oAW Workflow --> Eclipse EMFT Modeling Workflow Engine (MWE)
• oAW Xpand/Xtend --> Eclipse M2T Xpand
• oAW Xtext --> Eclipse TMF Xtext

Beginnend mit Eclipse 3.5 M7 sollte jeder oAW Anwender testen, ob seine oAW Projekte unter Verwendung der Plugins aus Eclipse Modeling fehlerfrei funktionieren und Fehler ggf. per Bugzilla melden.

Vielleicht wird sich mancher fragen: Wozu denn noch openArchitectureWare, wenn alles unter Eclipse in verschiedenen Projekten des Eclipse Modeling Projects ist ?

Eclipse Modeling umfasst eine Unmenge an Teilprojekten (siehe JAX Beitrag von Jan Köhnlein „Eclipse Modeling Overview“).

oAW ist eine praxiserprobte und bewährte Zusammenfassung von einigen dieser Projekte zu einer Art Distribution, die es Anwendern erleichtert, MDSD im oAW - Style umzusetzen.

oAW ist ausserdem eine Community mit viel KnowHow und Support, wenn es um modellgetriebene Entwicklung geht - einfach mal reinschauen ins Forum.

Bitte testet also Workflow (Eclipse MWE), Xpand (Eclipse M2T) und Xtext (Eclipse TMF) - und bleibt dem oAW Projekt treu ;-)

ekke

OSGI Enterprise Applications: Monster Bundles from 3rdParty

Thu, 30 Apr 2009 11:16:29 +0200

Die (OSGI) - Welt könnte so schön sein, alles brave OSGI Bürger:

• ein JAR file == ein Bundle
• import-package genutzt für allgemeine Abhängigkeiten
• required-bundles wenn überhaupt nur im eigenen Namensraum
• ...

Wer aber OSGI Enterprise Businessanwendungen baut, wird auch 3rdParty Bundles / -Projekte / -Frameworks mit einzugliedern haben.

Und da kann es passieren, dass es auf den ersten Blick sehr gut aussieht: ein paar Bundles, sauber strukturiert, Dependencies sinnvoll, aber..... warum ist das core Bundle so groß ?

Hier ist die Auflösung „looking into 3rdParty OSGI bundles“ - vielleicht sind die Composite Bundles von OSGI R4.2 (hier und hier und Richard Halls Session at JAX09) eine Hilfe, so etwas zu kapseln ? Ich werde berichten...

ekke

JAX09 - HowTo build an OSGI EJB3 Server - Slides online

Wed, 29 Apr 2009 16:35:57 +0200

Letzte Woche war die JAX 2009 in Mainz - es war wieder eine sehr interessante Veranstaltung. Das Wichtigste sind für mich die persönlichen Kontakte und Diskussionen bis in die Nacht hinein.

Am Freitag während des OSGI Experts Day konnte ich einen Überblick geben über meinen OSGI EJB3 Server.

• Eclipse als IDE und Platform für RCP und Server
• OSGI - Equinox
• Eclipse PDE (OSGI Bundle Tooling)
• Eclipse Riena (Remoting, UI)
• EasyBeans (EJB3 OSGI Bundles)
• Drools (Regelmaschine, Business-Prozessfluss)
• redView (Riena EMF Dynamic Views)
• open-erp-ware (OSGI - ERP - Enterprise Application)
• Model-Driven Development (oAW - OpenArchitectureWare XPand, XTend, Xtext, Workflow)
• und mehr...

Die Slides können angesehen werden bei:

SlideShare (ohne die eingebetteten Screencasts)
Vimeo (als Video inkl. der Quicktime Bildschirmfilme)

Auf meine Session und die Diskussionen werde ich in den nächsten Tagen noch in weiteren Episoden meines VideoPodcasts bei ekkes - corner - tv.org detailliert eingehen.

ekke

redView - dynamic Views for Business Applications

Wed, 8 Apr 2009 21:01:17 +0200

Auf der diesjährigen EclipseCon in Santa Clara konnte ich das erste Mal das Open Source Projekt „ redView “ vorstellen, das von Florian Pirchner und mir gestartet wurde.

Die Session wurde ohne die üblichen „Folien-zum-Mitlesen“ gestaltet. Das Buch „Zen oder die Kunst der Präsentation“ hat mir einige Anregungen gegeben:

Wenn aber eine Session im ZEN - Style präsentiert wird, dann kann man die Slides hinterher nicht einfach zur Verfügung stellen, was ja auch nicht Sinn einer solchen Präsentation ist.

Die ausführlichen Informationen zur Session gibt es parallel in einem extra Dokument.

Diese technischen Details gibt es in Kürze auf der redView Seite zum Download.

Wer jetzt aber dennoch wissen möchte, worüber ich auf der EclipseCon gesprochen habe, der kann sich einen Video Podcast ansehen:

ekkes - corner - tv gestartet

Ergänzend zu meinen Blogs in deutsch und englisch wird es jetzt auch noch regelmäßig ergänzend oder begleitend dazu einen englischen Video Podcast geben bei ekkes - corner - tv.org:

Ich werde in diesen Video Podcasts berichten und live präsentieren aus den Bereichen:

• Eclipse als IDE und Platform für RCP und Server
• OSGI - Equinox
• Eclipse PDE (OSGI Bundle Tooling)
• Eclipse Riena (Remoting, UI)
• EasyBeans (EJB3 OSGI Bundles)
• Drools (Regelmaschine, Business-Prozessfluss)
• redView (Riena EMF Dynamic Views)
• open-erp-ware (OSGI - ERP - Enterprise Application)
• Model-Driven Development (oAW - OpenArchitectureWare XPand, XTend, Xtext, Workflow)
• und mehr...

Wer den Video - Podcast abonnieren möchte: einfach in den iTunes Store gehen und nach „ekkes-corner“ suchen und abonnieren. Es gibt zwei Formate: für iPod/iPhone und für Desktop/AppleTV). Alternativ zum iTunes Store direkt im Web lesen: ekkes-corner-tv.org oder von dort den RSS Feed abonnieren.

Die erste Episode befasst sich mit der redView Session von der EclipseCon.

Die EclipseCon war wie immer sehr anstrengend (kurze Nächte) - hat aber auch Spaß gemacht, all die Freunde zu treffen und viel Neues zu lernen.

Die nächsten Monate werden wieder sehr arbeitsintensiv:

• redView wird Anfang Mai veröffentlicht
• der OSGI - Equinox - Server muss unter Galileo laufen
• zum Sommer geht die ERP Enterprise App in den Livebetrieb

Ach ja: und in diesem Monat ist die JAX in Mainz, wo ich am OSGI Experts Day sprechen werde.

Es wird einige Blogs und Video Podcasts geben... stay tuned...

ekke

Mit RCP Views UML Diagramme betrachten

Thu, 19 Mar 2009 18:08:50 +0100

Wer kennt das nicht ? Als Softwarearchitekt steht man stolz mit UML - Diagrammen beim Business - Anwender - und der versteht das nicht, kann keine Abhängigkeiten, 0..1, 0..* - Beziehungen, Wertobjekte, Vererbungen mit seinen praktischen Anforderungen zusammenbringen.

Was wäre, wenn man dem Businessanwender auf Knopfdruck anstelle des UML Diagramms automatisch RCP - Views generieren könnte ? ...wo man auch die versteckten Kleinigkeiten sofort erkennt: ein column-length -Wert von > 30 wird z.B. als mehrzeiliges Feld dargestellt, Enumerations werden mit den einzelnen Literalwerten dargestellt, Indexfelder sind als required markiert usw.

Utopisch ?

So kann es aussehen:

aus UML Modell generiert mit openArchitectureWare

aus EMF Modell dynamisch angezeigt mit RedView

(Hinweis: die ersten 3 Karteireiter zeigen 0..1, bzw. 1..1 Beziehungen, die letzten beiden Karteireiter enthalten eine Table und sind 0..* oder 1..* Beziehungen)

Neugierig geworden ?

Dann am Donnerstag um 14:30, Raum 206, die Session

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

auf der EclipseCon besuchen !

Oder wer mehr über das damit zusammenhängende OSGI - Equinox - RIena - Easybeans Serverprojekt erfahren möchte, sollte auf die JAX09 zum OSGI ExpertsDay kommen.

ekke

Bücher und Konferenzen für Eclipse Plugin Entwickler

Thu, 29 Jan 2009 14:26:23 +0100

Das sind meine Top 3 von aktuellen Fachbüchern zur Entwicklung von Eclipse Plugins im Kontext von modellgetriebener Entwicklung und OSGI...

• OSGI Service Compendium
• EMF - Eclipse Modeling Framework
• eclipse Plug-Ins

... jetzt heisst es nur noch warten auf das neue RCP Buch und das Equinox Buch ;-)

Gestern habe ich in München Eric Clayberg und Dan Rubel getroffen und von Ihnen die neue Ausgabe ihres „eclipse Plug-ins“ Buches bekommen. Da ich aber nicht warten konnte, hatte ich das Plug-ins Buch schon vorher gekauft. Jetzt hat Florian Pirchner Glück und er bekommt eins ab - kann er sicher gut für die redView (Riena EMF Dynamic View) - Entwicklung gebrauchen.

Es gibt gute Nachrichten für UI Entwickler, die Riena Ridgets verwenden: die Unterstützung durch den SWT Designer wird besser werden, wie mir Eric versichert hat.

+

Übrigens: Wer es noch nicht weiss - Riena hat die Freigabe für die Version 1.0 bekommen - Glückwunsch.

Wir werden ebenfalls versuchen, dynamische SWT Components, die von redView erzeugt werden, im SWTDesigner einfügen zu können.

Dann wird es möglich sein, komplexe Fenster zu bauen, in die dynamische Komponenten eingesetzt werden - zB immer wiederkehrende Daten wie Adressfelder. ... natürlich inklusive Databinding, Riena Markers und mehr.

Wer zur EclipseCon fährt, sollte den Vortrag über redView nicht verpassen:
Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

Und wer nicht zur EclipseCON kann oder etwas mehr wissen möchte, über das Gesamtprojekt, der kann sich meinen Talk auf der JAX 09 / Eclipse Forum Europe 09 am OSGI Experts Day ansehen:
Wir bauen uns einen OSGI Enterprise EJB3 Server.

ekke

UserInterface in OSGI Enterprise Anwendungen

Wed, 21 Jan 2009 10:52:33 +0100

Weihnachten ist vorbei...

... und es wird Zeit, mal wieder etwas zu veröffentlichen. Die letzten Wochen waren geprägt von harter und intensiver Arbeit, um die OSGI Enterprise Anwendung voranzubringen. Derzeit liegt der Schwerpunkt auf der Ausgestaltung der Benutzeroberfläche (GUI).

Einen Teil der GUI - Entwicklung werde ich auf der EclipseCon 2009 präsentieren, zusammen mit Florian, dem Plug-In Entwickler des redView - Designers. (redView = Riena - EMF - Dynamic Views)

Die Idee zu redView wurde vor ein paar Monaten geboren, als ich Florian die Probleme mit einer GUI für eine umfangreiche ERP Anwendung schilderte. Eine Enterprise ERP Anwendung mit hunderten von Entities und einem hohen Anspruch an den Bedienungskomfort, muss mit einem GUI Designer erstellt werden.

Beim GUI Designer ist meine Wahl auf den SWTDesigner von Instantiations gefallen - aus meiner Sicht ein hervorragendes Werkzeug.

Eine ERP Enterprise Anwendung hat aber neben hoch spezialisierten Fenstern immer auch hunderte von Standard Fenstern, deren Aufbau ähnlich ist und sich zu einem grossen Teil von den darunterliegenden Datenmodellen ableiten lässt.

Da meine ERP Anwendung eh modellgetrieben ist (unter Einsatz von openArchitectureWare) liegt natürlich die Idee nahe, den Javacode zumindest der Standard Views zu generieren.

Aber wie das so ist mit generierten Fenstern in Business - Anwendungen: irgendwas soll dann doch wieder anders dargestellt werden. Wenn man dann diese Fenster mit dem SWTDesigner anpasst, ändert sich der Javacode und es kann nicht mehr neu generiert werden, d.h. der Pflegeaufwand bei Erweiterungen und Anpassungen des Modells ist groß. Aber immerhin: es ist eine gute Idee, sich Fenster für den ersten Start mit dem SWTDesigner vorzugenerieren, dann entfällt zumindest ein Teil der Arbeit.

Bei der Suche nach Konzepten, die die GUI - Entwicklung vereinfachen bin ich schon vor einiger Zeit auf Eclipse Riena gestossen. Riena wird in meinem Enterprise Projekt bereits für den remote Zugriff auf den Server genutzt. (Riena Remote OSGI Services)

Riena hat es ausserdem geschafft, die GUI Entwicklung für den Programmierer zu vereinfachen, indem die teilweise komplexe Programmierung von SWT Widgets durch Riena Ridgets gekapselt wird, ohne aber die Flexibilität aufzugeben, bei Bedarf auf alles drunterliegende zugreifen zu können.

Riena Ridgets enthalten darüber hinaus eine saubere Trennung von UI und Controller und eine vereinfachte Programmierung des Eclipse Databinding.

In Businessanwendungen unerlässlich sind Entscheidungen wie:

• soll dieses Element gezeigt werden abhängig vom Usecase oder Daten ?
• ist dieses Element ein Mussfeld (required ?)
• ist es ein read-only Feld ?
• gibt es Validierungsregeln auf Feldebene (Telefonnummer, BLZ, email, von-bis, Datum, ...)

Riena bietet das Konzept der Marker und Validierungen und UI Filter, das die Programmierung solch komplexer Anforderungen vereinfacht und ausserdem dafür sorgt, dass es in der GUI durchgängig identisch dargestellt wird.

Ein grosser Teil der Voreinstellungen für Marker und Validierungen lässt sich ebenfalls aus dem Entity - Datenmodell oder den Businessprozess - Modellen ableiten und generieren. (z.B. Attribute, die als Businesskey oder Index markiert sind, werden Mussfelder)

Nun ergibt sich beim Einsatz von Riena aber das Problem, dass sich die GUI im SWTDesigner nicht mehr so einfach bearbeiten lässt, da der Codegenerator vom SWT Designer das Riena - Konzept der Trennung zwischen Controller und UI noch nicht "kennt" - aber es gibt hoffentlich eine Lösung in Zukunft, um die Integration zu verbessern.

Riena bietet auch ein komplettes UI mit eigenem LookAndFeel, Navigation und sehr schön gestalteten Perspektiven an, wobei eine Perspektive einer Subapplication entspricht.

Die Riena Oberfläche ist sehr aufgeräumt, leicht zu bedienen und verwirrt einen Businessanwender nicht mit den vielen Funktionalitäten, die Eclipse RCP im Standard enthält. Aber Riena hat jeweils nur eine View an einer festen Position und es gibt viele Szenarien in einer ERP Anwendung, wo mehrere Fenster geöffnet sein müssen mit Drag and Drop zwischen den Fenstern usw. Da bin ich gespannt, was die nächsten Monate bringen, ob ma1n diese Anforderungen miteinander verbinden kann.

Aber all das löst immer noch nicht das Dilemma des Fensterdesigns in modellgetriebenen Anwendungen: was lässt sich generieren, ohne Flexibilität bei der Gestaltung der Fenster zu verlieren ?

Damit bin ich wieder zurück bei meinen Diskussionen mit Florian im Herbst 2008, wobei unsere Vision entstand:

Was wäre denn, wenn die GUI all den Komfort von Riena beinhaltet und dynamisch erzeugt wird zur Laufzeit aufgrund eines darunterliegenden Metamodells auf Basis von EMF Ecore ?

... und was wäre, wenn diese EMF Modelle der einzelnen Views selbst generiert werden durch openArchitectureWare aus den UML Daten- und Businessprozess - Modellen ?

... und dann einen grafischen Designer, mit dem der Businessanwender oder der Businessprogrammierer diese Views verändern kann ? (mit Drag and Drop die Reihenfolge / Position verändern, Validierungsregeln hinzufügen, (Riena) Marker hinzufügen / ändern, Fonts und Farben anpassen....)

... und dann müssten diese Änderungen, die im EMF Modell der View gespeichert sind, natürlich bei der nächsten Generierung erhalten bleiben, wenn sich im UML Modell etwas ändert.

Im Oktober war das noch eine Vision - jetzt wissen wir, dass es funktioniert (für das ERP Projekt werden bereits hunderte an Views aus dem UML Modell heraus generiert) und spätestens zur eclipseCon 2009 wird es präsentiert:
Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

Eine Entity im UML Modell

oAW Xtend erzeugt EMF Elemente aus Informationen aus UML Persistenz Profile

redView Designer mit generierten Elementen - das gelb hinterlegte Eingabefeld kommt vom Riena Marker „required“

Die EMF Outline View des Mitarbeiters mit generierten Elementen

Die dazu gehörige Properties View.

Es ist noch einiges an Arbeit, um alle Aspekte des Databindings, der Internationalisierung, Plattformunabhängigkeit (derzeit OSX und Windows getestet), sowie Styles und Themes umzusetzen.

Es waren harte Wochen und kurze Nächte, aber es macht Spass mit Flo zu arbeiten und eine Vision umzusetzen.

Jetzt wird die GUI in der ERP Enterprise Anwendung wie folgt erstellt:

• Standardfenster werden als EMF Modelle mit oAW generiert
• redView erzeugt dynamische Views aufgrund von EMF Modellen
• Spezialfenster können mit oAW vorgeneriert werden
• Standardfenster werden mit dem redView Designer bearbeitet
• Spezialfenster werden mit dem SWTDesigner bearbeitet
• Riena Ridgets mit Markern und Validierungen werden eingesetzt

Nachdem ich die letzten Jahre EMF nur indirekt benutzt habe und sich meine Generierungen mit oAW auf UML Modelle und Profiles beschränkten, bin ich jetzt auch bei EMF gelandet wie so viele andere auch. Die Flexibilität von EMF und die gute Integration in oAW begeistern mich - es war sehr einfach, UML- und EMF - Modelle gemeinsam zu nutzen.

Ich werde darüber noch detailliert berichten. Aufgrund der Komplexität wird hiermit eine weitere Blogserie gestartet "UI in OSGI Enterprise Anwendungen", wo ich natürlich auch auf einen Vergleich mit anderen Lösungen eingehe, bzw. zeige wie diese integriert werden können.

Es bleibt spannend - stay tuned.

Und: die anderen Blogserien übers Logging, Server, Declarative Services gehen auch weiter - es gehört ja alles zusammen.

ekke

EclipseCon 2009 Riena - EMF - oAW and more

Thu, 18 Dec 2008 11:57:42 +0100

Dieses Jahr werde ich die EclipseCon nicht nur als Besucher erleben, sondern auch einen Vortrag halten:

Dynamic Views for Business Applications (Riena + Eclipse Modeling: EMF, oAW)

Dies war die zweite gute Nachricht seit der W-JAX, wo ich „Member des oAW Teams“ wurde.

Ich freue mich schon und werde auch bis dahin im Blog noch einiges berichten über redView (Riena - EMF - Dynamic View), das Teil eines modellgetriebenen OSGI Client - Server - Systems ist und unter EPL als Open Source freigegeben wird.

Diese Woche war eine Update - Woche: OSX 10.5.6, MagicDraw 16.0, openArchitectureWare 4.3.1RC3 und RC4, Riena M6, EasyBeans neue Snapshots.

Nachdem das EasyBeans Team einige Erweiterungen für mich vorgenommen hat (zusätzliche Properties für Declarative Services) werde ich auch weiter berichten können über Equinox Declarative Services und den OSGI Enterprise Server.

stay tuned...

Logging in OSGI Enterprise Anwendungen, Teil 6

Wed, 10 Dec 2008 15:02:11 +0100

In diesem (sechsten) Teil meiner Blog - Serie "Logging in OSGI Enterprise Applications" geht es um das Zusammenspiel von LOGBack / SLF4J mit openArchitectureWare.

Die letzten Beiträge aus dieser Blogserie befassten sich alle mit der Runtime einer OSGI Enterprise Application. Das Client - Server - Projekt ist modellgetrieben auf der Basis von Eclipse Modeling: EMF, UML2 und als Herzstück openArchitectureWare.

Der MDSD - Aspekt der Anwendung wird in einer anderen Blogserie betrachtet.

Hier geht es ums Logging, wobei wir alles über SLF4J / LogBack umsetzen, wie in den vorherigen Beiträgen erläutert.

openArchitectureWare (oAW) in Target Platforms

Wer oAW in einer Target Platform konfiguriert und gleichzeitig als Logging Framework SLF4J mit den Bridges zu Commons Logging und Log4J einsetzt, bekommt ein Problem, da in vielen oAW - Bundles die Dependency zu Logging Bundles nicht über Import-Package sondern als Require-Bundle umgesetzt ist.

Es ist bereits ein Bugzilla eröffnet, damit die Dependencies zu „common“ Bundles mit Import - Package gelöst werden, um flexibler zu sein.

Wer es jetzt benötigt, kann das mit PDE - Hilfe schnell erledigen: Bundles in den Workspace holen, Dependencies anpassen, Bundle neu als Plug-In exportieren.

openArchitectureWare (oAW) Workflows

oAW Workflows haben einen eigenen Launcher (Run Configurations | oAW Workflow) und wir müssen den Classpath anpassen.

Wir clicken auf User Entries und dann Add Projects...

...wählen dann unsere Logging - Projekte aus

...und speichern die Änderungen mit Apply.

Im Projekt, das den oAW Workflow startet, muss die logback.xml (oder logback-test.xml) enthalten sein. In dieser Datei konfigurieren wir das Loggingverhalten des Workflows - egal ob Lognachrichten über Log4J, Commons-Logging oder OSGI LogServices erfolgen.

Zur Kontrolle starten wir den Workflow mit <configuration debug="true"> in der logback.xml.

Wenn alles korrekt konfiguriert ist, dann erhalten wir in der Konsole zuerst die logback - Konfiguration aufgelistet, bevor der Workflow startet und alle Logausgaben gehen wie konfiguriert auf unsere Appender (Console, Socket, usw)

• Teil 1: Ein Überblick
• Teil 2: Alle Log-Ereignisse aus "klassischen" Logging - Frameworks einsammeln
• Teil 3: Alle Log-Ereignisse aus OSGI Log Services einsammeln
• Teil 4: Logging innerhalb einer OSGI Enterprise Anwendung starten
• Teil 5: Konfiguration von LOGBack beim Einsatz in OSGI Enterprise Anwendungen
• Teil 6: Logging und openArchitectureWare Workflows
• Teil 7: ... folgt (Stay tuned...)

Im Zusammenhang ebenfalls interessant meine früheren Blogs zum Thema Logging und OSGI:

• Logging (Riena - EasyBeans - Equinox) reloaded
• Catch-22 Logging in OSGI Environments

Diskussionen zu diesem Blog bitte im englischen Blog hier.

Comparing Files And Folders After Codegeneration

Wed, 10 Dec 2008 07:44:17 +0100

Auch wenn die Möglichkeiten innerhalb von Eclipse sehr gut sind, wenn es darum geht, Dateien umzubennen oder Dateien zu vergleichen, so benötige ich auch externe Tools:

Vor einiger Zeit hatte ich beschrieben, wie man unter OSX mit dem NameChanger (Freeware) auf einfache Weise Dateien umbenennen kann, die z.B. nicht wie Eclipse Bundles mit name_version benannt sind.

Für die Erstellung von Locations meiner Target Plattformen benötige ich ein Tool, das es mir erlaubt eindeutige Sets von Dateien (Bundles) zu erzeugen. In meinen Blogeintrag „Avoid Duplicate Bundles“ habe ich den Einsatz von FileMerge (unter OSX Bestandteil der XCode Tools) beschrieben.

Jetzt war ich auf der Suche nach einem intelligenten Tool, das es mir erlaubt festzustellen, ob generierter Code identisch zu einer älteren Version ist. Dabei handelt es sich um generierten Code, der in keinem Sourcecode Repository ist, da er komplett generiert wird. Vor der Generierung werden die entsprechenden Sourcecode - Verzeichnisse gelöscht, daher gibt es auch keine lokale History in Eclipse.

Während des Testens des 4.3.1RC2 von openArchitectureWare hat es mich interessiert zu wissen, ob der generierte Code identisch ist zur Version 4.3.0.

Zu beachten ist, dass es einige erlaubte Unterschiede gibt, z.B:

* generation started at: 9. Dezember 2008 08:04:13 CET

ist identisch zu Zeilen mit einem anderen Generierungsdatum. FileMerge von OSX war keine grosse Hilfe, da es solche Dateien als unterschiedlich gemeldet hat.

Nächster Versuch: Compare Folders erlaubt mir, die Grösse der Dateien festzustellen und ob Dateien hinzugefügt oder entfernt wurden.

Aber ich möchte es genauer wissen und habe DeltaWalker gefunden, das all das ermöglicht, was ich benötige und das beste ist:

DeltaWalker ist eine Eclipse RCP Anwendung :-)

...und verfügbar für OSX, Windows, Linux. Und jetzt war es ganz einfach, festzustellen, ob der generierte Code identisch ist:

Einen Datei - Filter erzeugen, der alle Dateien als identisch ansieht, wo es nur Differenzen in der Codezteile mit dem Generierungsdatum gibt:

Einen Ordner - Filter erzeugen, der die OSX-spezifischen .DS_Store Dateien unterdrückt:

Dann die Verzeichnisse vergleichen:

Alles identisch :-)

Glückwunsch openArchitectureWare

- keine Unterschiede zwischen 4.3.0 und 4.3.1RC2 beim Generieren festgestellt.

Ohne den Datei - Filter listet DeltaWalker die Unterschiede wie folgt auf:

...ich vermute, dass DeltaWalker mir noch oft gute Dienste erweisen wird.

Properties in Declarative Services und ServiceTracker

Thu, 4 Dec 2008 13:12:23 +0100

Ich habs ja schon in meinem letzten blog Dependencies und Services in OSGI Enterprise Anwendungen vermutet, dass da eine kleine Serie draus wird ;-)

ServiceTracker vs Declarative Services

Diesen Punkt habe ich im letzten Beitrag nur kurz angesprochen - hier folgen ein paar weitere Tips beim Umgang mit Properties.

Der ServiceTracker erhält aufgrund des Filters

final String filterPool = "("
+Constants.OBJECTCLASS
+ "="
+ JDBCPoolComponent.class.getName()
+")";

Services vom Typ JDBCPoolComponent - uns interessiert das Attribut JndiName:

private void processDataSources(JDBCPoolComponent service) {
if (service.getJndiName().equals("foo_entity_data_source_hsql")) {
// do something
}
}

Jetzt dieUmsetzung mit Declarative Services (equinox.ds):

In der Referenz der Service Komponente möchten wir feststellen, wenn exakt ein bestimmter JDBCPoolComponent Service verfügbar ist, da wir dann wissen, dass die DataSource bereitsteht.

Die erste Idee, die Referenz zu deklarieren, könnte sein:

Aber die Referenz wird nicht aufgelöst. Wie finden wir die Ursache heraus ? Dazu prüfen wir zunächst, ob der Filter korrekt ist und das Interface.

Tip: In der Equinox OSGI Konsole den Filter austesten !

Wir starten die OSGI Anwendung und geben diesen Befehl in der OSGI Konsole ein:

services (&(objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)(jndiName=foo_entity_data_source_hsql))

Es wird kein Service aufgelistet: No registered Services.

Als nächstes suchen wir nur nach allen Services des Interfaces JDBCPoolComponent:

services (objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)

Jetzt werden mehrere Services aufgelistet - darunter unser gesuchter:

{org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent}={classname=org.ow2.easybeans.component.jdbcpo......, xmlconfig=<?xml v..........iver" jndiName="foo_entity_data_source_hsql" password="ea......., service.id=80}
Registered by bundle: .../easybeans-component-jdbcpool_1.1.0-M3-SNAPSHOT.jar/

Im aufgelisteten Text entdecken wir auch jndiName="foo_entity_data_source_hsql"
Sehen wir genauer hin, stellen wir fest, dass dem Property xmlconfig mehrere Informationen zugewiesen sind. Das ist die Lösung:

services (&(objectclass=org.ow2.easybeans.component.jdbcpool.JDBCPoolComponent)(xmlconfig=*foo_entity_data_source_hsql*))

Der gesuchte Service wird gefunden und wir können in der Service Komponente die Referenz wie folgt eintragen:

Warum hat der ServiceTracker getJndiName() gefunden, der target Filter aber nicht ?
getJndiName() ist eine Methode des Services JDBCPoolComponent, aber nicht als Property in der Service Registry bekannt ! Target Filter können nicht auf Methoden der Implementierung zugreifen, sondern nur auf Service Properties.

Hinweis:
Wen die Thematik von OSGI Enterprise Anwendungen interessiert, sei auf meine Blogserien hingewiesen.

Ausserdem habe ich einige Submissions zur EclipseCon 2009 eingereicht -
Wer meine Erfahrungen live erleben möchte: Kommentare sind willkommen ;-)

Dependencies und Services in OSGI Enterprise Anwendungen

Tue, 2 Dec 2008 15:04:22 +0100

Das wird wieder eine intensive Woche:

• Umbau meines OSGI Enterprise Servers: Declarative Services anstatt ServiceTracker
• openArchitectureWare 4.3.1RC1 ist erschienen und muss getestet werden mit meinen Modellierungstemplates
• Weitere Tests von Eclipse 3.5M3 durchführen: PDE - Unterstützung für Declarative Services, Cycles in 3rd Party Bundles
• Entwicklung von redView (Riena - EMF - Dynamic Views) und Integration in meinen Modellierungsworkflow

Aber jetzt zum Thema dieses Blogs:

Dependencies und Services in OSGI Enterprise Anwendungen

Wer meine Blogserie „HowTo Build an OSGI Enterprise Server“ verfolgt, hat im letzten Beitrag gesehen, dass es bei den vielen Abhängigkeiten sehr schwierig wird, das alles mit einem ServiceTracker zu managen. Daher werden die dort definierten Anforderungen alternativ soweit möglich und sinnvoll mit Declarative Services umgesetzt.

PDE Tooling

Das erste, was sofort beim Arbeiten mit Declarative Services auffällt, ist das fehlende Tooling: wir müssen die Service - Component in einer XML Datei beschreiben:

... und einen Verweis auf die Service Komponenten in der MANIFEST.MF eintragen:

Ab Eclipse 3.5 wird dies besser: PDE Tooling unterstützt Declarative Services :-)

Managing Dependencies

Unter OSGI ist die Verwaltung der Abhängigkeiten eine wichtige Sache und nur eine gut durchdachte Struktur ergibt eine gute Anwendung.

Bisher kennen wir Abhängigkeiten über Import-Package oder Require-Bundle. Diese Abhängigkeiten können wir uns auch anzeigen lassen.

Klassisch als Plug-In - Dependencies:

oder visuell:

(hier ist die Updatesite des Graph Visualization Plug-Ins)

Aber die Bundle - Abhängigkeiten sind nur die eine Seite der Wahrheit, denn sie berücksichtigt nicht die Service - Abhängigkeiten.

Betrachten wir das DataSource Beispiel (s.o.):

Wir haben Abhängigkeiten: Der DataSourceService wird nur zur Verfügung gestellt, wenn jeweils exakt ein Service vom Typ Ejb3ServerComponentsService und JDBCPoolComponent vorhanden ist. Diese beiden Services sind in zwei anderen Bundles deklariert.

Wenn wir in der Service Komponente für diese Services bind / unbind Methoden definiert hätten, dann wären auf diesem Wege Bundle - Abhängigkeiten über Import-Package entstanden.

Bisher habe ich noch kein Tool gefunden, das Service - Abhängigkeiten für Equinox visuell aufzeigt.

Die Thematik ist aber noch wesentlich umfangreicher, denn wir haben verschiedene Strategien, um mit OSGI Services umzugehen:

• Declarative Services (wie hier beschrieben)
• ServiceTracker
• Riena-Service-Injection
• ...

Als Architekt benötige ich den Überblick über Bundles, Services und deren Abhängigkeiten. Daher werde ich in meinem modellgetriebenen Serverprojekt den anderen Weg gehen und die Abhängigkeiten modellieren.

Dann mit openArchitectureWare daraus die Service - Komponenten als XML - Datei erzeugen oder Javacode für ServiceTracker, bzw. Riena - Injection je nach gewählter Strategie.

Aber dies ist ein Thema für einen anderen Blogeintrag ;-)

Declarative Services trace - debug - log

Während des Refactorings meines Serverprojekts bin ich natürlich an den Punkt gekommen, wo ich mich gefragt habe, warum bestimmte deklarative Serviceabhängigkeiten nicht aufgelöst wurden ;-)

Mit Unterstützung der Equinox - Newsgroup und intensivem Googeln habe ich ein paar wichtige System Properties kennengelernt, die ich in der Dokumentation nicht gefunden habe:

• equinox.ds.debug=true schaltet den Debugmode ein
• equinox.ds.print=true gibt die Logausgaben auf die Konsole - benötige ich nicht, da ich die LogService Ausgaben abfange und logge (s.a. Blogserie Logging)
• equinox.ds.perf=true gibt in ms die Ausführungszeiten aus
• equinox.scr.waitTimeOnBlock=10000 gibt an, wieviel ms equinox.ds warten soll, bis eine Service Komponente erstellt wurde. War sehr hilfreich, als einige 3rdParty Komponenten im DEBUG Modus Zeiten von mehr als 50000 ms benötigten.

ServiceTracker vs Declarative Services

Kann ein Service Tracker komplett durch Declarative Services ersetzt werden ? Nein - das geht leider nicht.
Im ServiceTracker gibt es Zugriff auf alle Methoden eines Services - bei den Declarative Services kann man aber z.B. im target - Filter nur auf die Service Properties zugreifen, die der ServiceRegistry zur Verfügung stehen.

Soweit ein erster Bericht über Declarative Services - vielleicht entwickelt sich auch aus diesem Thema eine Blogserie - ich denke es ist interessant für viele Projekte.

Wen die Thematik von OSGI Enterprise Anwendungen interessiert, sei auf meine Blogserien hingewiesen.

Ausserdem habe ich einige Submissions zur EclipseCon 2009 eingereicht -
Wer meine Erfahrungen live erleben möchte: Kommentare sind willkommen ;-)

HowTo Build an OSGI Enterprise Server: EasybeansServiceTracker

Fri, 21 Nov 2008 17:23:38 +0100

Im vorigen Teil dieser Blogserie haben wir gesehen, dass es beim Einsatz von EasyBeans einiges zu beachten gibt bzgl. Startreihenfolge, Serviceabhängigkeiten usw. Zu diesem Zweck haben wir ein „Server - Agent“ - Bundle angelegt, das diese Vorgänge überwacht und steuert.

Innerhalb des „Server - Agent“ - Bundles befindet sich der EasybeansServiceTracker, dessen Aufgaben wir hier genauer beschreiben.

Damit wir EasyBeans nutzen können, stellen wir zunächst sicher, dass alle EasyBeans Components gestartet sind. EasyBeans Components sind:

Welche der EasyBeans Components benötigt werden, hängt von den Projektanforderungen ab.

Eine Komponente ist besonders wichtig, damit die EJB Bundles von EasyBeans korrekt verwaltet werden können: JDBCPool. Diese Komponente registriert die DataSources als JNDI Name.

Nachdem sichergestellt ist, dass alle EZB Komponenten registriert sind und die JDBCPool Komponente alle DataSources registriert hat, können wir unsere „PersistenceContext - Bundles“ und „EJB - Bundles“ starten. Dabei ist wichtig, dass die „PersistenceContext - Bundles“ zuerst gestartet werden, damit Referenzen aus den „EJB - Bundles“ vom EasyBeans EJB3 Container aufgelöst werden können.

Während der Erzeugung eines EJB3 - Containers für jedes „PersistenceContext - Bundle“ und jedes „EJB - Bundle“ registriert EasyBans für jedes Business - Interface (@Local, @Remote) einen ManagedService. Der EasybeansServiceTracker trackt alle Remote - Business - Interfaces und registriert diese als Riena Remote Endpoints.
Wenn der EJB3 Container durch EasyBeans fertiggestellt wurde, wird ein EZBContainerService registriert. Das Vorhandensein aller EZBContainerServices für all unsere Bundles führt dann zur Registrierung des RienaEasybeansServerService: unser Server ist einsatzbereit.

Der EasybeansServiceTracker

Jetzt sollte die Logik im Tracker so ähnlich aussehen:

Ist der ServiceTracker die ideale Lösung ?

Es ist natürlich recht übersichtlich, die ganze Logik „rund um die EasyBeans EJB3 - Container“ an einer zentralen Stelle in unserem EasybeansServiceTracker zu halten und es funktioniert auch.

Aber bei genauer Betrachtung ist es sehr komplex und schwierig zu managen - zumal unter Beachtung der Nebenläufigkeit. Ausserdem widerspricht es der Flexibilität einer dynamischen OSGI Anwendung: wie soll bei all diesen Abhängigkeiten innerhalb des Servcicetrackers auf das Stoppen / Starten von Bundles oder Services reagiert werden ?

Daher werden wir die gesamte Thematik der EJB3 - Container innerhalb unserer OSGI Enterprise Anwendung im nächsten Beitrag soweit wie möglich über Declarative Services zu lösen versuchen. Jeder kann dann entscheiden, welche Lösung besser gefällt.

Den Index der Blogserie finden Sie hier - Diskussionen bitte in der englischen Ausgabe.