Вие мислите по-лесно и по-бързо е да го направите с JDBC, защото не обмисляте реалната операционна среда на телефони и преносими устройства. Те често имат нестабилна свързаност чрез прокси сървъри за пренаписване на бъгове и безумни защитни стени. Те обикновено използват мрежов транспортен слой, който има високи и променливи скорости на загуба на пакети и латентности, които варират в много порядки за кратки периоди от време. TCP наистина не е страхотен в тази среда и особено се бори с дълготрайните връзки.
Основното предимство на уеб услугата е, че тя:
-
Има краткотрайни връзки с минимално състояние, така че е лесно да се върнете там, където сте били, когато устройството превключва WiFi мрежи, към/от клетъчна, губи връзка за кратко и т.н.; и
-
Може да преминава през всички, освен най-ужасните и драконовски уеб прокси
Ще рутинно срещнете проблеми с директна JDBC връзка. Едно предизвикателство е надеждно изключване на времето на мъртвите връзки, повторно установяване на сесии и освобождаване на заключвания, държани от старата сесия (тъй като сървърът може да не реши, че е мъртъв, в същото време, когато клиентът го прави). Друга е загубата на пакети, причиняваща много бавни операции, продължителни транзакции на база данни и последващи проблеми с продължителността на заключването и задачите за почистване на транзакциите. Освен това ще срещнете всякакъв вид безумни и счупени прокси и защитни стени под слънцето - прокси сървъри, които поддържат CONNECT но след това се оказва, че приема, че целият трафик е HTTPs, и го променя, ако не е; защитни стени с бъги за проследяване на връзката, които водят до неуспех на връзките или преминаване в полуотворено зомби състояние; всеки проблем с NAT, който можете да си представите; носители, които "полезно" генерират TCP ACK за намаляване на латентността, без значение проблемите, които причиняват при откриването на загуба на пакети и оразмеряването на прозореца; странно блокиране на портове; и др.
Защото всички използва HTTP, можете да очаквате това да работи - поне значително по-често от всичко друго. Това е особено вярно сега, когато обичайните уебсайтове използват стил на комуникация REST+JSON дори в мобилни уеб приложения.
Можете също така да напишете обажданията на вашата уеб услуга да бъдат идемпотентни използване на уникални токени за заявка. Това позволява на приложението ви да изпраща повторно заявки за модификация без страх, че ще извърши действие срещу базата данни два пъти. Вижте idempotence и дефиниране на идемпотентност .
Сериозно, JDBC от мобилно устройство може да изглежда като добра идея сега - но единственият начин, по който дори бих го помислил, би бил, ако всички мобилни устройства бяха в една високонадеждна WiFi мрежа под мой пряк контрол. Дори тогава бих го избягвал поради съображения за управление на производителността на базата данни, ако можех. Можете да използвате нещо като PgBouncer за обединяване на връзки между много устройства от страната на сървъра, така че обединяването в пул не е голям проблем, но почистването на загубени и изоставени връзки е, както и tcp keepalive трафикът, необходим, за да работи и дългото спиране транзакции от изоставени връзки.
