Sie denken Mit JDBC ist dies einfacher und schneller, da Sie die reale Betriebsumgebung von Telefonen und tragbaren Geräten nicht berücksichtigen. Sie haben oft eine schwache Konnektivität durch fehlerhafte Proxys zum Umschreiben des Datenverkehrs und verrückte Firewalls. Sie verwenden normalerweise eine Netzwerktransportschicht mit hohen und variablen Paketverlustraten und Latenzen, die in kurzen Zeitspannen um viele Größenordnungen variieren. TCP ist in dieser Umgebung wirklich nicht großartig und hat besonders mit langlebigen Verbindungen zu kämpfen.
Der Hauptvorteil eines Webdienstes besteht darin, dass er:
-
Verfügt über kurzlebige Verbindungen mit minimalem Status, sodass es einfach ist, dorthin zurückzukehren, wo Sie waren, wenn das Gerät zwischen WLAN-Netzwerken wechselt, zu/von Mobilfunknetzen wechselt, die Verbindung kurzzeitig verliert usw.; und
-
Kann alle bis auf die schrecklichsten und drakonischsten Web-Proxys passieren
Sie werden routinemäßig auf Probleme mit einer direkten JDBC-Verbindung stoßen. Eine Herausforderung besteht darin, tote Verbindungen zuverlässig zu timen, Sitzungen wiederherzustellen und Sperren freizugeben, die von der alten Sitzung gehalten wurden (da der Server möglicherweise nicht gleichzeitig mit dem Client entscheidet, dass er tot ist). Ein weiterer Grund sind Paketverluste, die zu sehr langsamen Vorgängen, Datenbanktransaktionen mit langer Laufzeit und daraus resultierenden Problemen mit Sperrdauern und Transaktionsbereinigungsaufgaben führen. Sie werden auch jede Art von verrückten und kaputten Proxys und Firewalls unter der Sonne treffen - Proxys, die CONNECT unterstützen aber dann nehmen Sie an, dass der gesamte Verkehr HTTPs ist, und verstümmeln ihn, wenn dies nicht der Fall ist. Firewalls mit fehlerhafter zustandsbehafteter Verbindungsverfolgung, die dazu führen, dass Verbindungen fehlschlagen oder in einen halboffenen Zombie-Zustand wechseln; jedes NAT-Problem, das Sie sich vorstellen können; Netzbetreiber generieren "hilfreich" TCP ACKs, um die Latenz zu reduzieren, ganz zu schweigen von den Problemen, die bei der Erkennung von Paketverlusten und der Fenstergröße auftreten; verrückte Portblockierung; usw.
Weil alle HTTP verwendet, können Sie davon ausgehen, dass das funktioniert - zumindest wesentlich häufiger als alles andere. Dies gilt insbesondere jetzt, da gängige Websites den REST+JSON-Kommunikationsstil auch in mobilen Web-Apps verwenden.
Sie können Ihre Webdienstaufrufe auch als idempotent schreiben Verwendung eindeutiger Anforderungstoken. Dadurch kann Ihre App Änderungsanforderungen erneut senden, ohne befürchten zu müssen, dass sie eine Aktion für die Datenbank zweimal ausführt. Siehe Idempotenz und Idempotenz definieren .
Ernsthaft, JDBC von einem mobilen Gerät könnte jetzt wie eine gute Idee aussehen - aber die einzige Möglichkeit, die ich überhaupt in Betracht ziehen würde, wäre, wenn die mobilen Geräte alle in einem einzigen hochzuverlässigen WiFi-Netzwerk unter meiner direkten Kontrolle wären. Selbst dann würde ich es aus Gründen des Datenbank-Performance-Managements vermeiden, wenn ich könnte. Sie können so etwas wie PgBouncer verwenden, um Verbindungen zwischen vielen Geräten auf der Serverseite zu bündeln, sodass das Verbindungspooling kein großes Problem darstellt, aber die Bereinigung verlorener und abgebrochener Verbindungen ist, ebenso wie der TCP-Keepalive-Verkehr, der erforderlich ist, damit es funktioniert, und der lange ins Stocken geraten ist Transaktionen von abgebrochenen Verbindungen.
