This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

Kommunikationsprotokoll / RESTful

Allgemeine Fragen zur Entwicklung von und mit JVx.

Kommunikationsprotokoll / RESTful

Postby jsmw » Fri Jun 10, 2011 7:36 am

Könnten Sie posten, wie das Kommunikationsprotokoll zwischen Client und Server aufgebaut ist (evtl. Beispiel).

Hat die JVx-Kommunikation Vorteile oder Nachteile gegenüber RESTful-Services im Sinne einer Service-Oriented-Architecture?

Kann auf eine DBStorage (Tabelle) auch in folgender Form zugegriffen werden?
Code: Select all
... = connection.callAction("getUsers");
... = connection.callAction("getOrders", <Parameter für WHERE oder SQL-Statement>);  // dynamische Filterung
jsmw
 
Posts: 38
Joined: Tue May 24, 2011 6:33 pm

Re: Kommunikationsprotokoll / RESTful

Postby Development@SIB » Fri Jun 10, 2011 1:48 pm

Kann auf eine DBStorage (Tabelle) auch in folgender Form zugegriffen werden?

JVx setzt eine 3-tier Architektur um und erfordert dadurch auch eine gewisse Umgewöhnung im Vergleich zur 2-tier Arbeitsweise. Die Architektur selbst und auch JVx bieten jedoch unterschiedlichste Verwendungsmöglichkeiten.
Es ist natürlich auch mit 3-tier möglich Statements direkt zu definieren. Der Entwickler muss dann aber wissen das am Client mehr Logik und Informationen zu finden sind als nötig. Wenn Where Bedingungen am Client zusammengesetzt oder ev. sogar Tabellennamen definiert werden, dann sind diese Informationen im Prinzip "jederzeit" auslesbar!

Mit einer sauberen 3-tier Verwendung ist das nicht der Fall. Und noch dazu bleibt die Business Logik wiederverwendbar und unabhängig vom Client!

Wenn Sie Statements vom Client an den Server schicken wollen, dann gibt es hierfür ein Beispiel das als Grundlage für weitere Ideen dienen kann: SQL Statements vom Client auswerten.

Generell ist der Weg mit RemoteDataBooks zu bevorzugen. Dabei können sowohl Conditions als auch SortDefinitions verwendet werden. Den Rest übernimmt die Storage. Weiters besteht immer die Möglichkeit mit eigenen Storages zu arbeiten, wie z.B. Twitter Storage oder dieses Beispiel.


Könnten Sie posten, wie das Kommunikationsprotokoll zwischen Client und Server aufgebaut ist (evtl. Beispiel).

Einleitend ist zu sagen, daß JVx protokoll unabhängig arbeitet und eine saubere Trennung zwischen der Protokoll-Verwendung (Connections) und dem tatsächlich implementierten Protokoll hat. Welches Protokoll für die Kommunikation zum Einsatz kommt ist also wählbar. Es gibt bereits unterschiedliche Implementierungen, siehe HttpConnection vs. VMConnection vs. DirectServerConnection.

Das Protokoll selbst ist weniger interessant als die übertragenen Daten. Für den Objekt-Austausch zwischen Client und Server werden in Java gerne serialisierte Objekte verwendet. Die Standard Serialisierung in Java ist allerdings nicht sehr Speicher sparsam und es kommt auch schon mal zu Problemen wenn am Server andere Objekte Versionen als am Client vorhanden sind. Das müssen gar nicht unbedingt eigene Klassen sein. Weiters wird es schwierig ein serialisiertes Java Objekt in anderen Technologien wie z.B. .NET zu verwenden. Dazu müsste dann schon der Serialisierungsmechanismus übernommen werden!

Um all diese Probleme zu vermeiden, verwendet JVx einen eigenen Serializer, der einerseits Speicher sparsam arbeitet und noch dazu Technologie unabhängig ist. Eine Referenz Implementierung für .NET gibt es bereits. Weitere Informationen, siehe Objekte Serialisieren.


Hat die JVx-Kommunikation Vorteile oder Nachteile gegenüber RESTful-Services im Sinne einer Service-Oriented-Architecture?

Beides funktioniert. Wenn Sie einen JVx Client für bestehende REST Services erstellen wollen, dann müssen Sie passende Storages implementieren und der Client arbeitet wie üblich. Auch hier ist unser Twitter Beispiel passend.

Wenn Sie die JVx Daten für andere Clients via REST Services anbieten wollen dann fehlt im Moment eine allgemeine Implementierung in JVx. Beim PLAT_Forms Contest 2011 haben wir aber ähnliches umgesetzt. Sie können natürlich auch selbst mit Frameworks wie RESTlet oder Jersey, ihre Daten bereitstellen.

Die Vor- und Nachteile ergeben sich ev. aufgrund von Projekt Anforderungen. Wenn RESTful als einzige Lösung in Frage kommt, wäre es schwer mit den Vorteilen von JVx zu argumentieren. Aber grundsätzlich hatten wir mit JVx noch keine Probleme.
User avatar
Development@SIB
 
Posts: 325
Joined: Mon Sep 28, 2009 1:54 pm

Re: Kommunikationsprotokoll / RESTful

Postby jsmw » Fri Jun 10, 2011 9:55 pm

Bei der Frage zum Protokoll geht es mir darum, was der Client an den Server (und zurück) per Default sendet und entsprechend vom Server oder Client nach einer Kommunikation abgefragt werden kann. (Session, SessionContext und andere Werte wie "name der invoke(...)-Method vom LOC )

Zu den Vor-/Nachteilen zu RESTful-WS würde mich interessieren, ob evtl. RESTful bei der Performance Vorteile hat. Mir ist aufgefallen, dass RemoteDataBook bei der Kommunikation mit DBStorage vor dem tatsächlichen Abholen von Daten einiges aufbauen(kommunizieren ?) muss und es anscheinend nicht in einem request-response Schritt wie bei RESTful erfolgt. Ich vermute, dass eine mehrfache, wenn auch besser optimierte, Kommunikation im WAN langsamer wäre, als nur 'eine' nicht so gut komprimierte Kommunikation.

...
connection.open(); //subconnection
...
datasource.open();
...
rdbContacts.open(); // Oder, geschieht bis hier keine Komm. mit Server?

Wenn ich es richtig verstanden habe, ist
- RemoteDataBook das Model und
- RometeDataSource der Proxy für die Kommunikation mit DBStorage (für die De-/Serialisierung zuständig?) und
- Connection der Kanal für die Kommunikation (Session-Management)

Bei den JVx-Demos wird, wenn eine Tabelle mit einer Form verknüpft ist, beim Wechsel von einem Datensatz auf den nächsten, der Datensatz vom Server neu geladen, obwohl die Datensätze, wie in der Tabelle ersichtlich, bereits am Client liegen. Durch diese ständige Kommunikation kommt es bei langsameren Leitungen zu Verzögerungen. Ist dieses Verhalten einstellbar?
jsmw
 
Posts: 38
Joined: Tue May 24, 2011 6:33 pm

Re: Kommunikationsprotokoll / RESTful

Postby Development@SIB » Fri Jun 10, 2011 11:55 pm

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.
User avatar
Development@SIB
 
Posts: 325
Joined: Mon Sep 28, 2009 1:54 pm

Re: Kommunikationsprotokoll / RESTful

Postby jsmw » Sat Jun 11, 2011 12:13 pm

Vorab Danke für die ausführlichen Infos!

Zu Demo Kontakt und Nachladen:
Wenn ich es also richtig verstehen, wird bei diesem Demo 'Kontakt' nur deshalb nachgeladen, weil im Formular (Delail-Maske) auch noch eine Detail-Tabelle 1:n 'Ausbildung' integriert ist. Wäre diese Tabelle nicht in der Maske, dann würde bei einem Zeilenwechsel kein Nachladen notwendig sein, weil die Daten fürs Formular bereits in der Tabelle vorhanden sind.
Beim zweiten Aufruf einer Zeile wird der Cache verwendet.

Zum REST und Requests:
Die Prüfung der Berechtigung bei Aufruf einer Funktion bzw. eines Objekts kann meines Erachtens auch in einem Request erfolgen. Wenn erlaubt, werden die Daten gesendet und wenn nicht eine Fehlermeldung, deshalb verstehe ich den zusätzlichen Request nicht. Zu dem könnte der Programmierer die GUI des Clients beim/nach Login dynamisch aufbauen, so dass der User nur die erlaubten Menus angezeigt bekommt. Dies würde wie bei CRUD die Kommunikation von dzt. (?) 2x bei Caching [connection.open(); rdbContacts.open();] auf 1x reduzieren.

Ich dachte das WebUI ist ExtJS und deshalb nach dem Start relativ komplett im Browser. War mir nicht klar das bei jedem Menu-Aufruf das GUI vom Server geladen werden muss. jQuery finde ich eine interessante Überlegung.
jsmw
 
Posts: 38
Joined: Tue May 24, 2011 6:33 pm

Re: Kommunikationsprotokoll / RESTful

Postby Development@SIB » Sat Jun 11, 2011 1:01 pm

Bei den Educations handelt es sich um eine n:m Beziehung. Die Daten werden geladen solange sie noch nicht geladen wurden. Wenn Sie von Zeile 1 auf 2 wechseln werden die Details geladen, beim zurückwechseln nicht mehr weil schon geladen. Ohne Details auch kein weiterer Request - genau!

WebUI ist mit extGWT (GXT) umgesetzt und läuft auch komplett im Browser, dennoch müssen die Events Ihrer JVx Applikation behandelt werden z.B. Button click oder DataBook Events. Der Client ist sozusagen eine Runtime die unabhängig von der Applikation funktioniert. Daher kann auch jede JVx Applikation ohne Source Code Änderung als Web App gestartet werden. Und genau aus diesem Grund wäre es problemlos möglich einen reinen Javascript Client zu erstellen, denn JVx WebUI läuft Event gesteuert - wenn nötig auch ohne UI für Test Robots.

Bei den Request kommt es auf die Sichtweise an. Natürlich könnte mit einem Request die Applikation ein auto-login durchführen, dann den Screen öffnen und auch noch die Daten aus dem Response setzen. Aber es ist ein Unterschied ob eine RIA oder eine Web App verwendet wird. Bei klassischen Web Apps wird 1 Request geschickt, am Server passieren viele weitere Abfragen/Funktionsaufrufe und am Ende wird das Ergebnis dem Client präsentiert. Ev. gibt es noch einige async calls aber das hängt vom UI ab.

Wenn Sie das ganze aus der Sicht des Applikations- Frameworkentwicklers betrachten ändert sich das ganze, denn es gibt unterschiedliche Objekte die unabhängig voneinander funktionieren und es ist nicht immer möglich alles in einen Request/Respone zu verpacken. Aber klar wäre es möglich auch mit Swing einen Runtime Client zu entwickeln der mit einem Request auskommt.

Aber um es auf den Punkt zu bringen - JVx kommuniziert nur wenn unbedingt nötig und das sehr optimiert. Abhängig von den Caching Einstellungen wird die Kommunikation nochmals reduziert und in Zukunft wird eine weitere Request Reduzierung Einzug halten. Wir haben JVx auch mit Packung! auf einem Android Smartphone laufen und selbst mit Edge (GPRS) funktioniert die Kommunikation reibungslos. Auch dort kommen Connection und RemoteDataBook zum Einsatz. Jede ausgewachsene Ajax Anwendung setzt mehr Requests ab als eine übliche JVx Anwendung im produktiv Betrieb.

Am besten Sie testen mit der JVxFirstApp selbst oder laden die Sourcen der Showcase Anwendung!
User avatar
Development@SIB
 
Posts: 325
Joined: Mon Sep 28, 2009 1:54 pm


Return to Development (DE)