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