DB adé, welcome to the Cloud!

Ein Gedanke der mich schon seit Wochen plagt und den ich nun mal aus meinem Kopf haben möchte, daher hier ein Post dazu.

Mit dem neusten Schrei Cloud Computing, Amazon EC2 usw. habe ich mich noch nicht sonderlich befasst, allerdings kam mir direkt eine Idee sowas ähnliches gebrauchen zu können....

Was wäre wenn...ich meine Applikation nicht komplett virtualisieren möchte, da sie ja keine reine Internet Applikation ist, sondern vielmehr eine Intranet Applikation, oder auch aus dem Grunde, dass ich nicht wirklich diesen großen Schritt auf einmal gehen möchte :-)

Zum Problem: Wie oft macht man sich schon beim Entwurf des Domain Modells Gedanken um Performanz. Ist dies in dieser Phase wirklich so berechtigt? Oder sollte man das Geschäftsmodell nicht einfach nach den wirklichen Business Requirements entwerfen und die Performance Leaks im Zuge der Iterationen aufdecken?!

Egal wie, aber im Endeffekt zielt vieles darauf ab, den DB Zugriff zu optimieren, d.h. auch das Domain Model zu verändern (was nicht immer im Sinne des Erfinders ist).

Also wie wäre es, wenn ich mir um die Persistenz (in Form einer DB) keine Gedanken machen müsste?

Wie wäre es wenn ein Freak mit viel Zeit daher käme und mir einen JPA Provider für eine Cloud anbieten würde?

Machen wir uns nicht zuviel Gedanken um Ausfallsicherheit und vollkommenes Data Recovery?

Also nehmen wir mal an, es gäbe da was, was mir eine saubere transaktionale Implementierung der JPA bietet, somit könnte ich diese ohne irgendwelche groben strukturellen Änderungen in meiner Applikation benutzen.

Engpässe wären lediglich im Netzwerk I/O zu sehen - da die Cloud ein SuperB Computer darstellt, der für mich als Anwender kein Nadelöhr in Sachen File I/O ist.

Was ich doch bis dato immer noch nicht verstehen kann, dass ich als Designer des Domain Models Rücksicht nehmen muss, auf irgendwelche alt hergebrachten Misstände der Datenbanken.

Vielleicht muss ich mich auch mit dem Thema Cloud Computing noch etwas mehr auseinander setzen. Als nächstes werde ich mir mal ansehen was das CloudTools Projekt (google hosted) zu diesem Thema beitragen kann und wie sich der Spring dm Server in dieses Environment integriert. So, stay tuned...

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).

Signup to EC2 Amazon WS

Da ich mir die Sache mit Cloud Computing mal näher ansehen wollte, zog ich in Erwägung mich bei Amazon EC2 anzumelden, allerdings haben mich die Terms of Use etwas verunsichert, wobei ich dies nun erst mal sein lasse, bis ich einen greifbaren Nutzen von dem Ganzen sehe.
Ich werde mal researchen was man so mit CentOS und CloudFoundry anstellen kann und ob ich den AWS Account wirklich brauche...

RAD mit RIA und "throwaway screens"?

Hallo zusammen,

heute möchte ich einmal ein Thema zum Nachdenken geben, was sicherlich den ein oder anderen plagt wenn er an seine schönen Webfrontends vergangener(!) Tage denkt. Ich möchte in diesen Zeit beginnen, als sich noch alles um Servlets drehte und alles voll und ganz aus HTML Rendering bestand. Was kam danach? JSP? Weil man das Problem der Servlets erkannte. Danach? Struts, JSF, ettliche JSF Komponentenbibliotheken inklusive Ajax Support. Irgendwann sollte man sich einmal fragen, tut es Not soviel Energie und Zeit in Screens mit
lästigem CSS Layout und JavaScript zu investieren? Diese womöglich noch mit Firebug zu tracen? Wie oft wird sich die Technologie im Frontend Bereich noch ändern?

Von daher pflege ich den Begriff der "Thowaway Screens", welchen ich eigentlich so genial im Zusammenhang mit Web Controllern fand ("Spring Recipes" von Mak/Apress).

Meiner Meinung nach müsste die Zeit nun vorbei sein, in der man unnötige Zeit mit dem Layout und dem Studieren von Komponenten verbacht hat. Als neuestes Baby habe ich AdobeFlex ausprobiert und bin von diesem Rapid Screen Development völlig begeistert. Die ersten Gehversuche unternahm ich mit BlazeDS zusammen mit dem gleichnamigen Spring Subprojekt. Recht früh bin ich dann zu GraniteDS und Cairngorm umgesiedelt was zusätzliche Vorteile bringt.

Wer also recht fix Webclients erstellen möchte sollte sich dies mal ankucken, wobei für den Anfang Spring BlazeDS sicherlich eine gute Unterstützung darstellt.

Grüßle,

JPA Entity Klassen in mehreren JAR Filex

Also zum Problem, an dem ich nun wieder seit Tagen rumgebissen habe:
Ich habe Entity Klassen in mehreren JAR Files und möchte diese innerhalb einer Webanwendung (WAR) deployen. Das Projektchen ist bzgl. Dependencies ungefähr wie folgt aufgesetzt: entity1.jar, entity2.jar werden von einer Service Layer Implementation service.jar benutzt. Alle drei zusammen werden in einer Flex Webanwendung (könnte auch sonst ein Client sein) benutzt, liegen somit im WEB-INF/lib folder.

Nun ja, soweit eigentlich noch kein Problem, aber wohin mit der persistence.xml? Diese darf natürlich nicht ein einer der beiden entity.jars liegen da sie sonst nur für dieses JAR zählt. Dann die logische Frage: Wer braucht eigentlich alle Entities? Das ist der Service (oder auch Integration) Layer, also dort ins META-INF. Somit funktionierts. Oder auch in WEB-INF/classes/META-INF, allerdings ist dies keine Angelegenheit der Webanwendung itself.

Kleiner Seiteneffekt während der Entwicklung in Eclipse: Man muss natürlich die persistence.xml aus den Domain Object Projekten entfernen, das kann allerdings zu Problemen mit dem Eclipse Dali JPA Validator führen, da der nicht mehr weiss gegen wen oder was er validieren muss.

Flex coden mit Eclipse aber ohne Plugin

Mühseelig ist es schon auf die Features von FlexBuilder zu verzichten, da ich aber unter Ubuntu Linux arbeite und es kein deb Package gibt und ich mir auch nicht stundenlang die Mühe machen wollte das ganze Teil zu kompileren, habe ich kurzentschlossen das Flex Plugin von Amateras installiert und für die Codevervollständigung im XML Editor von Eclipse das Flex3 XML Schema eingebunden.
Das Schema wird eben leider nicht mit dem SDK geliefert, kann aber natürlich generiert werden. Für die Komponenten des SDK zu haben hier. Und falls jemand für eigene MXML Komponenten ein Schema generieren möchte hier gleich das Eclipse Plugin mit dem dies möglich sein sollte :-).

Geht auch ohne FlexBuilder (zumindest bis noch bis heute ... )

Ach ja, da gibts noch ein ganz ganz leckeres kleines Framework GraniteDS um sich von vorhandenen Domainobjekten die passenden ViewObjekte in AS3 generieren zulassen. Ein Must!

Installation svn/javasvn/rapidsvn 1.4.6 auf Ubuntu 8.04/8.10

Möchte man eine ältere Version von Subversion auf Ubuntu Hardy Herion oder Intrepid installieren empfiehlt sich folgendes:

• Die Packages downloaden, nicht mit Synaptic installieren
• Download und Install der Binaries von libsvn1
• Download und Install der Binaries von subversion
  
• Download und Install der Binaries von libsvn-java
• Download und Install der Binaries von libsvncpp0c2a
  
• Download und Install der Binaries von rapidsvn_0.9.4-3

Danach sollte man mit Synaptic prüfen ob die richtige Version (z.B. 1.4.6) aller Packages installiert ist und diese dann gegen Upgrades sprerren (Lock Version)

Das Paket libsvn-java ersetzt das ältere libsvn-javahl! JavaHL wird bekanntlich für Java SVNClient wie Subclipse benötigt.

Auf keinen Fall sollte man in Versuchung kommen libsvn-javahl installieren. Dies ist ein Dummy Package und upgraded die betroffenen svn Packages auf die neuste Version!

Damit Eclipse die JavaHL Libraries beim Start findet, fügt man
-Djava.library.path=/usr/lib/jni
als vmargs hinzu.

(Getestet auf Intrepid mit SVN 1.4.6 und Eclipse 3.3,3.4)

Relationship Annotations in @Embeddable unzulässig (JPA1.0)

Laut JPA 1.0 Specification ist der Gebrauch von Relationships in @Embeddable annotierten Klassen unzulässig, somit ist die Idee von embedded Valueobjects in Entities nur halbherzig durchgezogen worden (... ein fine-grained Domainmodel sollte doch guter Stil sein!?)

Es bleibt also abzuwarten was JPA2.0 in diesem Sinne bringt.

Beispiel:

@Embeddable
public class UserDetails implements Serializable {

@OneToMany(mappedBy ="id") // unzulaessig!!
private Set emails = new HashSet();

...
}

... wäre schön, ist aber nicht. Die @Embeddable annotierte Klasse darf lediglich einfach annotierte Properties (Basic, Column, Lob, Temporal, Enumerated) enthalten (siehe Kap. 9.1.34/JPA1.0 Spec)