Desktop-Version als Offline-Version
5 posts
• Page 1 of 1
Desktop-Version als Offline-Version
Hallo,
wir überlegen gerade, euer Framework zu verwenden. Dazu eine Frage.
Das ist uns klar:
Ich nehme mal an, dass die Kommunikation der diversen Oberflächen mit dem Server über diverse Webservices funktioniert.
Wir hätten nun aber die zusätzliche Anforderung, dass die Desktop-Version auch offline funktionieren soll. Also wir bräuchten da ein lokales Duplikat der Datenbank (Synchronisation mit den "online"-Daten ist nicht notwendig). Welche Konzepte sind da mit JVx vorhanden, um das realisieren zu können?
Danke und freundliche Grüße
Martin Zeller
wir überlegen gerade, euer Framework zu verwenden. Dazu eine Frage.
Das ist uns klar:
"Sie schreiben den Source Code für die Benutzeroberfläche nur einmal und die Applikation kann als Desktop, Web oder Mobile Applikation gestartet werden."
Ich nehme mal an, dass die Kommunikation der diversen Oberflächen mit dem Server über diverse Webservices funktioniert.
Wir hätten nun aber die zusätzliche Anforderung, dass die Desktop-Version auch offline funktionieren soll. Also wir bräuchten da ein lokales Duplikat der Datenbank (Synchronisation mit den "online"-Daten ist nicht notwendig). Welche Konzepte sind da mit JVx vorhanden, um das realisieren zu können?
Danke und freundliche Grüße
Martin Zeller
- mzeller
- Posts: 27
- Joined: Tue Apr 19, 2016 10:48 am
- Location: Vienna
Re: Desktop-Version als Offline-Version
Die Kommunikation funktioniert dzt. nicht über Webservices. JVx hat eine Protokoll unabhängige Kommunikation und im Moment gibt es eine direkte Kommunikation (selbe VM), http (zu eime Appserver, Servlet) oder auch Sockets (zu einem Socket Server mit JVx).
Das Protokoll kann einfach gewechselt werden durch die Verwendung der jeweiligen Klasse...
Die Applikation ist unabhängig davon, weil alles abstrahiert wurde in ein IConnection (Interface).
Die Kommunikation via http ist RPC ähnlich. JVx serialisiert und deserialisiert die Java Objekte. Aber ser/deserialisuerung wird nicht immer eingesetzt (z.B. nicht bei direkter Kommunikation).
JVx hat eine saubere 3-tier Architektur und dadurch können die einzelnen Schichten auch getrennt voneinander laufen oder aber alle zusammen (Desktop Applikation ohne Applikationsserver).
Der Switch kann recht einfach sein, weil man entweder gegen eine Online DB connected (2-tier) oder zum Applikationsserver (3-tier) oder zu einer lokalen DB. Man kann die Entscheidung transparent treffen oder überlässt es dem User.
Der Applikationscode selbst muss dafür nicht angepasst werden, da es dem "Client" grundsätzlich egal ist, woher die Daten kommen.
JVx hat keinen Code fix integriert um das Switching automatisch durchzuführen, aber alles andere ist bereits vorhanden.
Es gab auch diesbezüglich einen anderen Post
Das Protokoll kann einfach gewechselt werden durch die Verwendung der jeweiligen Klasse...
Die Applikation ist unabhängig davon, weil alles abstrahiert wurde in ein IConnection (Interface).
Die Kommunikation via http ist RPC ähnlich. JVx serialisiert und deserialisiert die Java Objekte. Aber ser/deserialisuerung wird nicht immer eingesetzt (z.B. nicht bei direkter Kommunikation).
JVx hat eine saubere 3-tier Architektur und dadurch können die einzelnen Schichten auch getrennt voneinander laufen oder aber alle zusammen (Desktop Applikation ohne Applikationsserver).
Der Switch kann recht einfach sein, weil man entweder gegen eine Online DB connected (2-tier) oder zum Applikationsserver (3-tier) oder zu einer lokalen DB. Man kann die Entscheidung transparent treffen oder überlässt es dem User.
Der Applikationscode selbst muss dafür nicht angepasst werden, da es dem "Client" grundsätzlich egal ist, woher die Daten kommen.
JVx hat keinen Code fix integriert um das Switching automatisch durchzuführen, aber alles andere ist bereits vorhanden.
Es gab auch diesbezüglich einen anderen Post
-
Development@SIB - Posts: 325
- Joined: Mon Sep 28, 2009 1:54 pm
Re: Desktop-Version als Offline-Version
Wenn die Applikation als z.B Webvariante läuft (mit Vaadin), dann wird eine direkte Kommunikation eingesetzt und die Applikation selbst läuft am Applikationsserver.
Wenn der Client zu einem Applikationsserver connected, wird eine Http Connection verwendet.
Je nach "Applikationsmodus" wird entschieden welche Kommunikation die beste ist.
Wenn der Client zu einem Applikationsserver connected, wird eine Http Connection verwendet.
Je nach "Applikationsmodus" wird entschieden welche Kommunikation die beste ist.
-
Development@SIB - Posts: 325
- Joined: Mon Sep 28, 2009 1:54 pm
Re: Desktop-Version als Offline-Version
Danke für die ausführlichen Antworten!
Verstehe ich euch richtig:
wir könnten die Weboberfläche normal über die HttpConnection laufen lassen (mit Applikationsserver) und die Desktopvariante mittels DirectServerConnection und z.B. H2-Datenbank, wo kein Applikationsserver mehr notwendigt ist. Stimmt das so?
Danke
Martin
Verstehe ich euch richtig:
wir könnten die Weboberfläche normal über die HttpConnection laufen lassen (mit Applikationsserver) und die Desktopvariante mittels DirectServerConnection und z.B. H2-Datenbank, wo kein Applikationsserver mehr notwendigt ist. Stimmt das so?
Danke
Martin
- mzeller
- Posts: 27
- Joined: Tue Apr 19, 2016 10:48 am
- Location: Vienna
Re: Desktop-Version als Offline-Version
Beinahe.
Mal angenommen die Weboberfläche ist Vaadin. Dann läuft sowohl die GUI als auch die Business Logik am Server und da wäre eine HttpConnection zu viel des guten, aber klar ginge es. Bringt aber keinen Vorteil weil bei HttpConnection noch zusätzlich ser/deserialisiert wird.
Es wäre aber beispielsweise möglich, die Server zu splitten, sprich die GUI auf Server 1 laufen zu lassen und die Business Logik auf Server 2. Das wäre durch die saubere Schichtentrennung von JVx möglich, aber nicht wirklich praktisch für normale Anwendungen. Wir haben aber durchaus solche Installationen.
Die Desktop Variante kann mit DirectServerConnection betrieben werden, oder auch einer HttpConnection. Die DirectServerConnection ist natürlich etwas praktischer, weil einfach nicht serialisiert wird für den Objekttransfer. Die HttpConnection ser/deserialisiert die Objekte vor dem Versand/Empfang.
ABER die Connection selbst ist nicht wichtig für die DB, weil die Connection nur die Verbindung zwischen GUI und Business Logik übernimmt. Entscheidend ist, wo die Business Logik läuft: Lokal, auf einem embedded Applikationsserver (z.B. Tomcat embedded) oder auf einem entfernten Applikationsserver. Dem GUI ist es im Grunde auch egal ob eine DirectServerConnection, HttpConnection oder sonstiges verwendet wird. Das ist vollkommen transparent und unabhängig in der Entwicklung.
Aber um eine Lösung zu beschreiben:
Wenn eine Applikation entwickelt werden soll, die sowohl lokal als auch Remote DBs verwenden soll, dann sollte die GUI und Business Logik im Applikations jar enthalten sein und natürlich sollte auch die Business Logik am Applikationsserver installiert sein, es sollte die DirectServerConnection für den lokalen Modus verwendet werden und die HttpConnection oder ev. eine SocketConnection für den Zugriff auf das Remote System. Die Business Logik muss wissen, ob lokal oder Remote gearbeitet wird. Das kann entweder über eine Connection Property gelöst werden oder im lokalen Modus wird ein Singleton/statisches Konstrukt(Util Klasse) verwendet. Die Business Logik ist immer die gleiche, egal ob Lokal oder Remote. Lediglich das Öffnen der DB Connection ist unterschiedlich (Connect String).
Natürlich muss die Applikation auch prüfen ob lokal oder Remote gearbeitet werden soll um ggf. eine automatische Datenmigration durchzuführen usw... Das ist aber dann Logik die Applikationsspezifisch ist.
Wir haben mit JVx schon Anwendungen entwickelt die Off/Online funktionieren, ohne großen Mehraufwand. Lediglich die Migration der Daten ist immer wieder eine Herausforderung. Aber dieses Problem ist, egal mit welchem Framework, immer vorhanden.
Mal angenommen die Weboberfläche ist Vaadin. Dann läuft sowohl die GUI als auch die Business Logik am Server und da wäre eine HttpConnection zu viel des guten, aber klar ginge es. Bringt aber keinen Vorteil weil bei HttpConnection noch zusätzlich ser/deserialisiert wird.
Es wäre aber beispielsweise möglich, die Server zu splitten, sprich die GUI auf Server 1 laufen zu lassen und die Business Logik auf Server 2. Das wäre durch die saubere Schichtentrennung von JVx möglich, aber nicht wirklich praktisch für normale Anwendungen. Wir haben aber durchaus solche Installationen.
Die Desktop Variante kann mit DirectServerConnection betrieben werden, oder auch einer HttpConnection. Die DirectServerConnection ist natürlich etwas praktischer, weil einfach nicht serialisiert wird für den Objekttransfer. Die HttpConnection ser/deserialisiert die Objekte vor dem Versand/Empfang.
ABER die Connection selbst ist nicht wichtig für die DB, weil die Connection nur die Verbindung zwischen GUI und Business Logik übernimmt. Entscheidend ist, wo die Business Logik läuft: Lokal, auf einem embedded Applikationsserver (z.B. Tomcat embedded) oder auf einem entfernten Applikationsserver. Dem GUI ist es im Grunde auch egal ob eine DirectServerConnection, HttpConnection oder sonstiges verwendet wird. Das ist vollkommen transparent und unabhängig in der Entwicklung.
Aber um eine Lösung zu beschreiben:
Wenn eine Applikation entwickelt werden soll, die sowohl lokal als auch Remote DBs verwenden soll, dann sollte die GUI und Business Logik im Applikations jar enthalten sein und natürlich sollte auch die Business Logik am Applikationsserver installiert sein, es sollte die DirectServerConnection für den lokalen Modus verwendet werden und die HttpConnection oder ev. eine SocketConnection für den Zugriff auf das Remote System. Die Business Logik muss wissen, ob lokal oder Remote gearbeitet wird. Das kann entweder über eine Connection Property gelöst werden oder im lokalen Modus wird ein Singleton/statisches Konstrukt(Util Klasse) verwendet. Die Business Logik ist immer die gleiche, egal ob Lokal oder Remote. Lediglich das Öffnen der DB Connection ist unterschiedlich (Connect String).
Natürlich muss die Applikation auch prüfen ob lokal oder Remote gearbeitet werden soll um ggf. eine automatische Datenmigration durchzuführen usw... Das ist aber dann Logik die Applikationsspezifisch ist.
Wir haben mit JVx schon Anwendungen entwickelt die Off/Online funktionieren, ohne großen Mehraufwand. Lediglich die Migration der Daten ist immer wieder eine Herausforderung. Aber dieses Problem ist, egal mit welchem Framework, immer vorhanden.
-
Support@SIB - Posts: 353
- Joined: Mon Sep 28, 2009 1:56 pm
5 posts
• Page 1 of 1