Die Daten die tatsächlich übertragen werden können mit einem Protokoll Analyse Tool z.B. WireShark betrachtet werden. Oder die Unit Tests für den UniversalSerializer ansehen.
In einem LCO steht prinzipiell der
SessionContext zur Verfügung und alles was dieser Context an Methoden und Objekten anbietet ist verfügbar wie z.B. die Session, die Inject Objects, die
Properties.
Die Performance hängt einerseits von der Anzahl an Requests und natürlich auch von den übertragenen Daten ab. Wobei die Daten nicht so sehr ins Gewicht fallen im direkten Vergleich zwischen den Lösungen.
Wenn Sie REST Services verwenden wollen für mehr als nur einfache Datenübertragung wie z.B. Session Management wie es JVx (stateless wohlgemerkt) übernimmt, dann reicht ein Request nicht aus. RESTful Services werden gerne für "einfache" CRUD Operationen eingesetzt, und weniger oft für komplexe Aufgabenstellungen wie es in klassischen Business Anwendungen der Fall ist (aber auch das gibt es natürlich).
Übrigens wird WADL bei REST Services eher selten verwendet im Gegensatz zu WSDL.
Wenn eine Connection geöffnet wird, erfolgt ein Request, da geprüft wird ob die Session aufgebaut werden darf sprich ob User/Pwd korrekt sind (MasterConnection) bzw. ob das LCO verwendet werden darf (SubConnection). Dafür wird in beiden Fällen der SecurityManager bemüht.
Weiters wird bei open() von RemoteDataBooks kommuniziert um die MetaDaten abzufragen, sprich welche Spalten gibt es, mit welchen Datentypen usw. Dieser Request ist abhängig von den Caching Einstellungen und im produktiven Betrieb ist üblicherweise kein zusätzlicher MetaDaten Request nötig. Während der Entwicklung ist der Cache nur für Testzwecke aktiviert, weil es einfach praktischer ist ohne Cache zu entwickeln. Genauere Informationen sind
hier und
hier zu finden.
Die Architektur ist nicht ganz richtig dargestellt, denn:
- IDataBook definiert das Model und MemDataBook bzw. RemoteDataBook sind die Standard Implementierungen. Das Model kennt weder Protokoll noch Serialisierung!
- Die RemoteDataSource "gruppiert" RemoteDataBooks und speichert lediglich die Connection. Die Kommunikation übernimmt das RemoteDataBook selbst. Außerdem ist die DataSource für Caching und den WriteBackIsolationLevel zuständig. Die DateSource hat keinen Bezug zur Serialisierung und hat auch nur inderekt Bezug zum Protokoll!
- Die Master- und SubConnection sind Hilfsklassen für die einfache Verwendung der tatsächlichen Protokoll Implementierung (siehe IConnection). Mit diesen Klassen kann unabhängig von der IConnection Implementierung immer gleich entwickelt werden - egal welches Protokoll eingesetzt wird.
- Eine IConnection Implementierung verwendet ein bestimmtes Protokoll und kümmert sich auch um die Serialisierung
In JVx wurden alle APIs sauber getrennt und alle Schichten sind austauschbar ohne Auswirkungen auf die Funktionalität.
Die Demos mit Swing/QT Client verwenden ein Client-Model mit IDataBooks und Daten werden nur geladen wenn nötig. Wenn die Zeile gewechselt wird, werden Detail Tables und deren Details natürlich on-demand geladen, sofern das noch nicht geschehen ist. Ein Reload würde klarerweise ein erneutes Nachladen auslösen. Aber im Normalfall bleiben die Daten erstmals gecached. Wenn es sich um ein simples Formular ohne Detail Tables handelt, so wird auf keinen Fall nachgeladen, außer die Tabelle hat so viele Zeilen, daß mit einem Request nicht alle Daten geladen werden konnten z.B. bei Millionen Datensätzen.
Anders ist das Verhalten jedoch mit der WebUI Implementierung, da die Applikation dabei am Server ausgeführt wird. Da wir kein eigenes Javascript Model verwenden, arbeiten die Tabellen unabhängig von den Editoren und somit erfordert ein Zeilenwechsel einen Update Request. Jedoch werden in einem Request sämtliche UI Änderungen übertragen und nicht nur die Werte der Editoren. Sollten also 20 Editoren angebunden sein, so wird max. 1 Request abgesetzt.
Ein eigenständiges Client-Model mit Javascript ,sozusagen ein abgespecktes MemDataBook, würde auch hier nochmals die Requests reduzieren. Doch im Moment sind wir mit dem WebUI ganz zufrieden.
Aufgrund der UI Abstraktion von JVx sind wir hier nicht auf eine Technologie fixiert und ev. gibt es auch eine reine Javascript Implementierung basierend auf JQuery.
Die Showcase Applikation verwendet kein globales MetaDaten Caching, auch bei Packung! kommt noch eine ältere JVx Version, ohne serverseitigem Cache, zum Einsatz.
In zukünftigen JVx Versionen ist hinsichtlich Request Anzahl noch etwas Einsparungspotential vorhanden und auch schon einiges geplant, da die IConnection bereits jetzt in einem einzigen Request beliebig viele Operationen ausführen kann. Dieses Feature wird bei RemoteDataBooks noch stärker zum Einsatz kommen.