JDO-JPA-Migrationsstrategien

Wäre dieser Artikel vor fünf Jahren entstanden, dann wäre die Migrationsrichtung der meisten Projekte sicherlich diese: Weg vom reinen JDBC oder weg von Container-Managed-Persistence hin zu JDO. Im Jahre 2003 erscheint mit JDO 1.0.1 ein Jahr nach der Verabschiedung von JDO 1.0 das erste kleinere Update der Spezifikation, welches auf Jahre hin die Basis einer Hand voll kommerzieller O/R-Mapper-Implementierungen bildet. JDO war damals aus architektonischer Sicht, wenn auch manchmal leicht polarisierend, die erste Wahl für die Persistenzstrategie einer Java-Enterprise-Anwendung. Im Vertrauen auf den Standard wurde eine JDO-Implementierung auch gerne anderen kommerziellen, aber nicht-standard-konformen O/R-Mapping-Frameworks vorgezogen. Heute, im Jahr 2008 sieht die Situation anders aus: Auch wenn JDO 2.0 die heute fortschrittlichste O/R-Mapping-Spezifikation für Java darstellt, kann das Interesse an ihr kaum geringer sein. Neue Projekte, die JDO den Vorzug geben, gibt es faktisch nicht mehr und in bestehenden Projekten ist ein gewisser Migrationsdruck weg von JDO zu verspüren. Wie eine solche Migration möglichst reibungslos vonstatten gehen kann, versucht dieser Artikel im Folgenden aufzuzeigen.
weiterlesen

Inszenierte Transparenz

Werden heute Java-Enterprise-Anwendungen entworfen, so muss als eine der ersten Entscheidungen die Art der Persistenz geklärt werden. Diese Frage bezieht sich dabei weniger auf den Datenspeicher – ein relationales Datenbanksystem kann stillschweigend vorausgesetzt werden – sondern auf den Umgang mit den Daten. Für den Architekten ergeben sich zwei grundlegende Marschrichtungen: Fasst er die Daten der Anwendung als grobgranulare, wenig vernetzte Dateneinheiten auf, so wird er zu einem tabellengetriebenen Ansatz tendieren und vorrangig Entwurfsmuster einsetzen, die dem relationalen Aggregatzustand der Daten geschuldet sind, so beispielsweise Row/Record Sets, Page Iterators oder Data Access Objects. Sieht der Architekt hingegen die Daten der Anwendung als feingranulare, stark vernetzte Entitäten an, so ist er mit einem objektorientierten Ansatz besser beraten. Da die Daten trotz objektorientierter Sichtweise in einer relationalen Datenbank landen, gilt es hier eine Brücke zwischen beiden Welten zu schlagen. Der Unterschied, oft verharmlosend als Impedanz-Unterschied bezeichnet, ist jedoch wohl bekannt und technisch beherrschbar [1].
weiterlesen

Transmission Impossible? Java5 Enumerationen und IIOP

Im September 2006 wird in der Java-to-IDL Revision Task Force Mailing List der Erweiterungsvorschlag für das Mapping von Java5-Enumerationstypen eingereicht [1]. Diesem Vorschlag wird ein Jahr später stattgegeben [2]. Die Java Language Specification für Java5 erscheint jedoch bereits 2005 – und das fast ein Jahr nach der ersten offiziellen Version von Java5 [3][4]. Erste Prototypen von Java5 standen der Allgemeinheit wahrscheinlich noch viel früher zur Verfügung. Damit vergingen mindestens drei Jahre seit der Verfügbarkeit der nativen Enumerationstypen in Java5 und deren Mapping auf CORBAs Interface Definition Language. Diese Verzögerung wirkt noch heute für all diejenigen nach, die den Versuch wagen, Java5 Enumerationsliterale über IIOP zu übertragen. Wie dies dennoch mit Java5-Bordmitteln möglich ist, beschreibt der Artikel im Folgenden.

weiterlesen

 Zurück 1 2 3 4 5 6