Vous pensez il est plus simple et plus rapide de le faire avec JDBC car vous ne considérez pas l'environnement d'exploitation réel des téléphones et des appareils portables. Ils ont souvent une connectivité flakey via des proxies de réécriture de trafic bogués et des pare-feu insensés. Ils utilisent généralement une couche de transport réseau qui présente des taux de perte de paquets élevés et variables et des latences qui varient sur plusieurs ordres de grandeur sur de courtes périodes. TCP n'est vraiment pas génial dans cet environnement et a particulièrement du mal avec les connexions de longue durée.
Le principal avantage d'un service Web est qu'il :
-
A des connexions de courte durée avec un état minimal, il est donc facile de revenir là où vous étiez lorsque l'appareil change de réseau WiFi, vers/depuis le cellulaire, perd brièvement la connectivité, etc. et
-
Peut traverser tous les proxys Web sauf les plus horribles et les plus draconiens
Vous allez régulièrement rencontrez des problèmes avec une connexion JDBC directe. L'un des défis consiste à temporiser de manière fiable les connexions mortes, à rétablir les sessions et à libérer les verrous détenus par l'ancienne session (car le serveur peut ne pas décider qu'il est mort en même temps que le client). Une autre est la perte de paquets qui entraîne des opérations très lentes, des transactions de base de données de longue durée et des problèmes conséquents avec les durées de verrouillage et les tâches de nettoyage transactionnelles. Vous rencontrerez également toutes sortes de proxys et de pare-feu insensés et cassés sous le soleil - des proxys qui prennent en charge CONNECT mais ensuite supposez que tout le trafic est HTTPs et mutilez-le si ce n'est pas le cas; des pare-feux avec suivi de connexion avec état bogué qui provoquent l'échec des connexions ou passent à un état zombie semi-ouvert ; tous les problèmes NAT que vous pouvez imaginer ; les transporteurs générant "utilement" des ACK TCP pour réduire la latence, sans parler des problèmes qui en résultent avec la découverte de la perte de paquets et le dimensionnement de la fenêtre ; blocage de port loufoque ; etc.
Parce que tout le monde utilise HTTP, vous pouvez vous attendre à ce que cela fonctionne - du moins, beaucoup plus souvent que toute autre chose. Cela est particulièrement vrai maintenant que les sites Web courants utilisent le style de communication REST+JSON, même dans les applications Web mobiles.
Vous pouvez également écrire vos appels de service Web pour qu'ils soient idempotents à l'aide de jetons de demande uniques. Cela permet à votre application de renvoyer des demandes de modification sans craindre d'effectuer deux fois une action contre la base de données. Voir idempotence et définir l'idempotence .
Sérieusement, JDBC à partir d'un appareil mobile peut sembler une bonne idée maintenant - mais la seule façon que j'envisagerais serait que les appareils mobiles soient tous sur un seul réseau WiFi hautement fiable sous mon contrôle direct. Même dans ce cas, je l'éviterais pour des raisons de gestion des performances de la base de données si je le pouvais. Vous pouvez utiliser quelque chose comme PgBouncer pour regrouper les connexions entre de nombreux appareils côté serveur afin que le regroupement des connexions ne soit pas un gros problème, mais le nettoyage des connexions perdues et abandonnées l'est, tout comme le trafic tcp keepalive nécessaire pour le faire fonctionner et le long bloqué transactions provenant de connexions abandonnées.
