Seit heute steht die Beta 1 von JVx 0.8 bereit. Die Versionsnummer deutet auf eher geringe Änderungen zum Vorgänger hin. Doch der Schein trügt. Wir haben extrem hohe Ansprüche in die Release 1.0 und erst wenn alle in unserem Team zustimmen, wird der Schritt gewagt. Auf dem Weg zu 1.0 warten also noch spannende und Feature geladene Versionen.

Was ist nun alles neu und warum lohnt sich der Umstieg?

Neben kleineren und notwendigen Bugfixes lag das Hauptaugenmerk auf

• Datenbankfeatures
• Technologie Unabhängige Kommunikation (C#, MONO)
• Erweiterungen im Bereich des Handling von Business Objekten
• Minimierung der Requests
• Code reviews

Wie bereits in einem meiner letzten Beiträge angedeutet, ist es mit JVx nun möglich die Business Logik für .NET/C# bzw. MONO Anwendungen anzubieten. Doch nicht nur die Business Logik an sich sondern im speziellen der Zugriff auf Datenbanken wird auf einfachste Art und weise ermöglicht. Sowohl mit Java als auch mit C# wird wie gewohnt gearbeitet. Die übliche IDE, die gewohnten Frameworks, die bekannten UI Komponenten. Vor allem mit Silverlight ist die Anbindung an JVx ein enormer Gewinn.

Zu den interessanten Datenbankfeatures zählen sicherlich die automatische Übernahme der Default Werte von Spalten und die Berücksichtigung von Check Constraints.
Die Default Werte werden wirksam wenn am Client ein neuer Datensatz erstellt wird. Dann werden die Default Werte vollautomatisch vorbelegt und die Eingabe wird für den Anwender um einiges einfacher und vor allem passieren weniger Fehler.
Die Check Constraints verwandeln einzelne Spalten automatisch in Choice Editoren, sprich der Anwender kann nur die erlaubten Werte eingeben. Im Falle von Ja/Nein Feldern müsste ansonsten immer und immer wieder ein J/N Choice Cell Editor definiert werden. Das erledigt nun JVx. Die einzige Bedingung ist ein sauberes Datenmodell.

Aber unabhängig von der Datenbank, stehen alle diese Features auch als API Funktionen zur Verfügung. Die Default Werte und die erlaubten Eingabewerte sind über Funktionen setzbar und können einfach in der Middleware festgelegt werden. Denn nicht jeder Java Entwickler ist zugleich ein Datenbank Spezialist.

Das wertvollste neue Feature ist aber unangefochten die Performancesteigerung bei der Übertragung der Meta Daten zwischen RemoteDataBook und DBStorage. Die Meta Daten werden nun Standardmässig pro RemoteDataSource gecached (im Normalfall existiert eine RemoteDataSource pro WorkScreen). Sollte ein WorkScreen z.B. 10 RemoteDataBooks enthalten, so wurden bisher 10 einzelne Requests benötigt. Nun reduzieren sich die Requests auf einen einzigen! Doch selbst dieser Request ist im produktiven Betrieb nicht nötig, da die Meta Daten im Normalfall nicht mehr geändert werden.
Aus diesem Grund wurde eine Cache Role eingeführt, die Wahlweise auf Global, DataSource oder Off gesetzt werden kann. Im Entwicklungsstadium verzichtet man auch gerne auf Caching.

Im Bereich der Business Logik wurde die Abhängigkeit zu GenericBean gelockert. Nun ist ein Lifecycle Objekt vom Typ Map ausreichend um die Server Objekte zu verwalten. Natürlich erhält man nur mit GenericBean den vollen Komfort, aber bei der Integration der JVx Lifecycle Objekte in z.B JSF oder Spring, verzichtet man schon mal auf diesen Komfort.

JSF, Spring und JVx? Mit der Beta 1 von JVx 0.8 wird die Integration möglich.

Eine genaue Übersicht der Änderungen finden sie in unserem Support System und der Roadmap zu JVx 0.8.