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.

Schon seit wir mit der Definition des ISerializer Interface begonnen haben, war der Wunsch nach Technologie unabhängiger Kommunikation vorhanden. Das Thema hat uns immer wieder gestreift, doch die Notwendigkeit einer Java unabhängigen Implementierung war nicht gegeben.

Vor einigen Wochen war es dann so weit. Wir entschieden uns für die Portierung der JVx Objekt Serialisierung nach C#. Natürlich gab es einige Herausforderungen und Probleme, die jedoch keinen Einfluß auf die Funktionswiese hatten. Und im Unterschied zu CORBA, Hessian & Co unterstützen wir ein sehr breites Spektrum an Objekten.

Nun ist endlich so weit und wir können eine funktionierende Kommunikation zwischen JVx und C# vermelden. Sämtliche Objekte werden mit dem UniversalSerializer ausgetauscht. Der C# Serializer arbeitet wie sein Java pendant und ist ebenso mächtig. Die Serialisierung von Objekten unterliegt allerdings den gleichen Einschränkungen wie es auch in Java der Fall ist, allerdings verzichten wir bei unserer Lösung auf das im Normalfall verpflichtende ISerializable Interface.

Um dem ganzen den notwendigen Schliff zu verpassen haben wir auch gleich die Kommunikationsklassen AbstractSerializedConnection, Master- und SubConnection sowie alle abhänigen Klassen portiert. Dadurch ist der Zugriff auf die JVx Business Logik zu 100% gegeben. Wir können nun die komplette Business Logik und alle Server seitigen Actions, auch mit C#, einsetzen und zwar ohne Mehraufwand.

Ein kleines C# Beispiel an dieser Stelle muss natürlich sein:

Im nächsten Schritt erstellen wir einen Showcase basierend auf Silverlight 4. Demnächst hier mehr dazu.

Die Entwicklungen an JVx 0.8 laufen bereits auf Hochtouren. Die erste Beta Version ist für Anfang April geplant.

Der Schwerpunkt liegt in den Bereichen

• Usability
• Vereinfachung und Komfort bei der Verwendung des API
• Kommunikation mit C# bzw. MONO
• Bugfixes

In der Roadmap ist der aktuelle Stand der Entwicklung ersichtlich.

In der Ausgabe 04.2010 des Java Magazin ist ein äußerst interessanter Artikel, von Florian Müller, über JVx erschienen. Dieser Artikel gibt einen kurzen Einblick in JVx, erläutert kurzerhand die Idee hinter JVx und zeigt ein kurzes Code Beispiel. Alles in allem, ein gelungener Einstieg von JVx in die Medienwelt.

Der Artikel zum Nachlesen: JVx Java Magazin 04.2010

Die kommende Ausgabe 05.2010 enthält einen Beitrag von mir, über die Umsetzung unseres Beitrages zur W-JAX Challenge 09. In dem Artikel erkläre ich was es mit JVx auf sich hat und anhand eines Beispiels versuche ich die Einfachheit und Effizienz zu verdeutlichen.

Der Artikel ist schon seit einigen Wochen bei IT-Republik zu finden: Hier