Den dollsten Clue habe ich mit dem Kauf eines Buchs von Apress bzgl. JEE6 und GlassFish v3 gemacht. Das war im vergangenen Jahr (als die Spez noch draft war und der Embedded Container noch unbrauchbar).
Das Buch ist sowas von schrecklich! Komplett für Rookies, voller Fehler und selbst die Code-Beispiele zum Download waren unbrauchbar,
Mich hatte interessiert ob ich die Instanziierung des Embedded EJBContainers korrekt gemacht hatte. Damals hatte ich unheimliche Hacks zu verrichten um das Ding mit Maven/Cobertura/Surefire gescheit zum Laufen zu bringen. Auf der Suche nach Hilfe fand ich einen brandaktuellen Eintrag im Forum von Sun. Dieser Eintrag kam von dem Autor des Buches, der ebenso um Hilfe schrie....
Mittlerweile ist der Autor in die Liga der Java Champions aufgestiegen. Ich vermute, dass ein Buch über Java Technologien die letzte Hürde war die es zu meistern galt :-)
Nun denn, dann fangen wir doch mal an Buuuuch zu schreiben ....
Donnerstag, 17. Juni 2010
Google Books macht mich traurig
Sehr sehr schade ...
Ich mag Bücher. Und noch mehr mag ich Fachbücher! Angefangen 1987 mit den Ausgaben des Amiga Magazins (die übrigens immer noch in Umzugskisten verweilen) bis zum heutigen Tag mit ganz tollen Büchern von Apress, Manning oder O'Reilly.
Gute Fachbücher muss man einfach kaufen, da man sie immer und immer wieder liest und stets Neues darin entdeckt. Deswegen sollte auch ein jeder die Arbeit des Autors schätzen und für den Druck das nötige Kleingeld hinlegen.
Nach der Welle der eBooks auf eDonkey, rapidshare & Co. findet man nun auch so manch tolles Werk auf books.google.com. Dieser Trendbewegung stehe ich momentan noch mit einem weinenden Auge gegenüber und weiss nicht Recht ob dies dem KnowHow der Menschheit dienlich ist oder nicht.
Der Erscheinungstermin von DocBook5 ist laut des Verlags O'Reilly schon wieder verschoben. Mittlerweile von Ende Mai auf Juli; wurde mir per Mail bestätigt. Schade, schade, dabei warte ich schon seit Anfang des Jahres (!) auf genau dieses Stück Papier.
Weder ebook, iPad, books.google können in meinem Bücherregal das Papier ersetzen ...
Ich mag Bücher. Und noch mehr mag ich Fachbücher! Angefangen 1987 mit den Ausgaben des Amiga Magazins (die übrigens immer noch in Umzugskisten verweilen) bis zum heutigen Tag mit ganz tollen Büchern von Apress, Manning oder O'Reilly.
Gute Fachbücher muss man einfach kaufen, da man sie immer und immer wieder liest und stets Neues darin entdeckt. Deswegen sollte auch ein jeder die Arbeit des Autors schätzen und für den Druck das nötige Kleingeld hinlegen.
Nach der Welle der eBooks auf eDonkey, rapidshare & Co. findet man nun auch so manch tolles Werk auf books.google.com. Dieser Trendbewegung stehe ich momentan noch mit einem weinenden Auge gegenüber und weiss nicht Recht ob dies dem KnowHow der Menschheit dienlich ist oder nicht.
Der Erscheinungstermin von DocBook5 ist laut des Verlags O'Reilly schon wieder verschoben. Mittlerweile von Ende Mai auf Juli; wurde mir per Mail bestätigt. Schade, schade, dabei warte ich schon seit Anfang des Jahres (!) auf genau dieses Stück Papier.
Weder ebook, iPad, books.google können in meinem Bücherregal das Papier ersetzen ...
Mittwoch, 16. Juni 2010
OSGi die µSOA!
Der Begriff SOA ist sehr geläufig. Dabei handelt es sich lax ausgedrückt um eine verteilte, lose gekoppelte heterogene Struktur von Applikationen die oftmals mittels einer Middleware (z.B. eines ESB) zusammenhängen. Jede dieser Applikationen bieten dabei der SOA ihre Services an.
Nimmt man eine Lupe zur Hand und schaut sich eine Applikation dieser SOA genauer an könnte man möglicherweise eine Applikation ausfindig machen, die auf OSGi aufgebaut ist und dedizierte Services der SOA anbietet.
Die Architektur einer solchen OSGi Anwendung hat gewisse Ähnlichkeit mit einer echten SOA. Alle OSGi Bundles sind autarke Softwarekomponenten die Services veräußern und der OSGi Runtime und damit anderen Bundles anbieten. Alle Komponenten sind dabei ebenso lose gekoppelt und können während des Betriebs aktiviert bzw. deaktiviert werden ohne größeren Schaden auf andere Komponenten auszuüben.
Die oben erwähnte Middleware ist zu vergleichen mit der OSGi Runtime. Ein vernünftiger OSGi Server wie der SpringSource dmServer bietet eine solide OSGi Laufzeitumgebung die keine Wünsche offen lässt.
Zum Thema Verteilung (wenn dies wirklich ein Thema sein sollte): "1st law of istribution is, don't distribute, if you don't and won't have to" (Martin Fowler).
Sollte man dennoch in die Verlegenheit kommen OSGi Services verteilen zu müssen, wäre vielleicht das Projekt R-OSGi der ETH Zürich ganz interessant.
µSOA!
Alles in allem könnte man also eine OSGi Applikation inkl. OSGi Runtime als eine µSOA bezeichnen.
Nimmt man eine Lupe zur Hand und schaut sich eine Applikation dieser SOA genauer an könnte man möglicherweise eine Applikation ausfindig machen, die auf OSGi aufgebaut ist und dedizierte Services der SOA anbietet.
Die Architektur einer solchen OSGi Anwendung hat gewisse Ähnlichkeit mit einer echten SOA. Alle OSGi Bundles sind autarke Softwarekomponenten die Services veräußern und der OSGi Runtime und damit anderen Bundles anbieten. Alle Komponenten sind dabei ebenso lose gekoppelt und können während des Betriebs aktiviert bzw. deaktiviert werden ohne größeren Schaden auf andere Komponenten auszuüben.
Die oben erwähnte Middleware ist zu vergleichen mit der OSGi Runtime. Ein vernünftiger OSGi Server wie der SpringSource dmServer bietet eine solide OSGi Laufzeitumgebung die keine Wünsche offen lässt.
Zum Thema Verteilung (wenn dies wirklich ein Thema sein sollte): "1st law of istribution is, don't distribute, if you don't and won't have to" (Martin Fowler).
Sollte man dennoch in die Verlegenheit kommen OSGi Services verteilen zu müssen, wäre vielleicht das Projekt R-OSGi der ETH Zürich ganz interessant.
µSOA!
Alles in allem könnte man also eine OSGi Applikation inkl. OSGi Runtime als eine µSOA bezeichnen.
Dienstag, 15. Juni 2010
Business Domain Modelling
Ein paar Gedanken zum Entwurf einen Domain Models...
Ich frage mich, wie viele Designer und Architekten den Weg zu einem stabilen Domain Model finden welches losgelöst jeglicher Technologie ist und auf eine lange Zeit Bestand hat?
Nehmen wir einmal den Entwickler als erstes Beispiel: Der Entwickler arbeitet am Liebsten in der IDE seiner Wahl und findet sich am besten in der Sprache seiner Wahl zurecht, welche sich letztendlich in Code ausdrückt. Da er glaubt mit den neuesten Standards und Hypes bewandert zu sein, entwirft er ein super-duper Domain Model in Sourcecode (am Besten OO mit POJOs). Metadaten dürfen im Code natürlich auch nicht fehlen, zumal es die Frameworks ja sogar anbieten (Bsp. JPA Annotationen).
Recht schnell wird ihm klar, dass das Ganze doch recht komplex wird aber es stört nicht weiter, da sich immer noch alles abbilden lässt bzw. er der Macher ist und (mittlerweile als Einzigster) den Überblick behält.
Anforderungen wie Langlebigkeit und Wartbarkeit sind erstmal zweitrangig, auch wenn der JCP bereits einen Draft der Folgeversion vorgelegt hat. Neuen Teammembers dieses monolithische Geflecht einzelner Klassen zu erklären und auch die Notwendigkeit der Beziehungen untereinander aufzuzeigen ist ein Genuss, da er sein Modell kennt und Javadoc sein bester Freund. Nur versteht dies jeder? Versteht dies auch der Business Analyst der die Anforderungen definiert hat? Fraglich...
Phase 2:
Sei es ein Technologiewechsel oder ein Upgrade, es ist Zeit, dass der Macher sein Modell upgraded (denn er versteht es am Besten). Reine Fleissarbeit...
Phase 3:
Neue Anforderungen landen im Jira. Denkbar wäre, dass das Modell (oder Teile davon) in eine WSDL gepackt werden, oder generell in ein Schema, um einem Legacy System anbieten zu können. Also basteln wir kurzer Hand ein XMLSchema und natürlich auch die Parser/Writer dazu. Allerdings sind somit unsere eigentlichen Informationen des Business Models redundant und voneinander unabhängig geworden. Noch schlimmer wird es wenn jemand verlangt abhängig von unserem Modell DAO Code (sei es SQL oder Java) zu erzeugen, also bauen wir uns ein Freemarker Template und die nächste Redundanz ist da.
Das Problem was ich aufzeigen möchte ist folgendes: Ist das Business Model nicht das zentrale Herzstück der Anwendung bzw. des gesamten Unternehmens? Und sollte dieses Modell nicht auch von Stakeholders begriffen werden, die sich nicht in den Tiefen unserer Kodierungssprache bewegen? Sollten wir uns nicht einen Schritt von dem Code wegbewegen und nochmals über die Methodologie nachdenken?
Mögliche Lösungsansätze ohne an Code zu denken:
1) UML: Sicherlich interessant nur Overkill. Ich möchte nicht jedes kleinste Detail mit UML modellieren und immer wieder den One-Way-Generator laufen lassen um zu sehen, dass ich ein perfekter Designer bin und mit dem grünen Knopf mein Modell in Code giessen kann. Dies ist einfach nicht effizient genug und wie erwähnt in den allermeisten Fällen eine Einbahnstrasse.
2) Einfache Modellierungssprachen (wie Ecore/EMF) bieten genug um ein Modell anschaulich darzustellen und begreiflich zu machen. Hat man sein Ecore Modell auf dem Desktop ist es lediglich eine Frage des Generators (bzw. des Templates) um jegliche Anforderungen zu erschlagen. Selbst der Business Analyst wagt sich das Modell zu öffnen und findet sich damit zuerecht. Der Vorteil gegenüber vielen kommerziellen UML Tools liegt in den M2T und M2M Transformationen die ich nach Belieben entwerfen kann um zum Ziel zu gelangen.
Wer also die Problemstellung kennt sollte sich die Geschwister Ecore/EMF/Xpand/Xtext und oAW anschauen. Vielleicht hilft dies weiter...
Ich frage mich, wie viele Designer und Architekten den Weg zu einem stabilen Domain Model finden welches losgelöst jeglicher Technologie ist und auf eine lange Zeit Bestand hat?
Nehmen wir einmal den Entwickler als erstes Beispiel: Der Entwickler arbeitet am Liebsten in der IDE seiner Wahl und findet sich am besten in der Sprache seiner Wahl zurecht, welche sich letztendlich in Code ausdrückt. Da er glaubt mit den neuesten Standards und Hypes bewandert zu sein, entwirft er ein super-duper Domain Model in Sourcecode (am Besten OO mit POJOs). Metadaten dürfen im Code natürlich auch nicht fehlen, zumal es die Frameworks ja sogar anbieten (Bsp. JPA Annotationen).
Recht schnell wird ihm klar, dass das Ganze doch recht komplex wird aber es stört nicht weiter, da sich immer noch alles abbilden lässt bzw. er der Macher ist und (mittlerweile als Einzigster) den Überblick behält.
Anforderungen wie Langlebigkeit und Wartbarkeit sind erstmal zweitrangig, auch wenn der JCP bereits einen Draft der Folgeversion vorgelegt hat. Neuen Teammembers dieses monolithische Geflecht einzelner Klassen zu erklären und auch die Notwendigkeit der Beziehungen untereinander aufzuzeigen ist ein Genuss, da er sein Modell kennt und Javadoc sein bester Freund. Nur versteht dies jeder? Versteht dies auch der Business Analyst der die Anforderungen definiert hat? Fraglich...
Phase 2:
Sei es ein Technologiewechsel oder ein Upgrade, es ist Zeit, dass der Macher sein Modell upgraded (denn er versteht es am Besten). Reine Fleissarbeit...
Phase 3:
Neue Anforderungen landen im Jira. Denkbar wäre, dass das Modell (oder Teile davon) in eine WSDL gepackt werden, oder generell in ein Schema, um einem Legacy System anbieten zu können. Also basteln wir kurzer Hand ein XMLSchema und natürlich auch die Parser/Writer dazu. Allerdings sind somit unsere eigentlichen Informationen des Business Models redundant und voneinander unabhängig geworden. Noch schlimmer wird es wenn jemand verlangt abhängig von unserem Modell DAO Code (sei es SQL oder Java) zu erzeugen, also bauen wir uns ein Freemarker Template und die nächste Redundanz ist da.
Das Problem was ich aufzeigen möchte ist folgendes: Ist das Business Model nicht das zentrale Herzstück der Anwendung bzw. des gesamten Unternehmens? Und sollte dieses Modell nicht auch von Stakeholders begriffen werden, die sich nicht in den Tiefen unserer Kodierungssprache bewegen? Sollten wir uns nicht einen Schritt von dem Code wegbewegen und nochmals über die Methodologie nachdenken?
Mögliche Lösungsansätze ohne an Code zu denken:
1) UML: Sicherlich interessant nur Overkill. Ich möchte nicht jedes kleinste Detail mit UML modellieren und immer wieder den One-Way-Generator laufen lassen um zu sehen, dass ich ein perfekter Designer bin und mit dem grünen Knopf mein Modell in Code giessen kann. Dies ist einfach nicht effizient genug und wie erwähnt in den allermeisten Fällen eine Einbahnstrasse.
2) Einfache Modellierungssprachen (wie Ecore/EMF) bieten genug um ein Modell anschaulich darzustellen und begreiflich zu machen. Hat man sein Ecore Modell auf dem Desktop ist es lediglich eine Frage des Generators (bzw. des Templates) um jegliche Anforderungen zu erschlagen. Selbst der Business Analyst wagt sich das Modell zu öffnen und findet sich damit zuerecht. Der Vorteil gegenüber vielen kommerziellen UML Tools liegt in den M2T und M2M Transformationen die ich nach Belieben entwerfen kann um zum Ziel zu gelangen.
Wer also die Problemstellung kennt sollte sich die Geschwister Ecore/EMF/Xpand/Xtext und oAW anschauen. Vielleicht hilft dies weiter...
Montag, 14. Juni 2010
JSR-222 Java Architecture for XML Binding
Check out this SlideShare Presentation:
JSR-222 Java Architecture for XML Binding
View more presentations from Heiko Scherrer.
Abonnieren
Posts (Atom)