Jij denkt het is eenvoudiger en sneller om het te doen met JDBC, omdat je geen rekening houdt met de echte wereld van telefoons en draagbare apparaten. Ze hebben vaak onbetrouwbare connectiviteit via herschrijvende proxy's voor verkeer met fouten en krankzinnige firewalls. Ze gebruiken meestal een netwerktransportlaag met hoge en variabele pakketverliessnelheden en latenties die in korte tijd over vele ordes van grootte variëren. TCP is echt niet geweldig in deze omgeving en worstelt vooral met langlevende verbindingen.
Het belangrijkste voordeel van een webservice is dat het:
-
Heeft kortstondige verbindingen met minimale status, dus het is gemakkelijk om terug te gaan naar waar u was toen het apparaat van WiFi-netwerk wisselde, van/naar mobiel, kortstondig de verbinding verliest, enz.; en
-
Kan alle behalve de meest vreselijke en draconische webproxy's passeren
U zult routinematig problemen ondervindt met een directe JDBC-verbinding. Een uitdaging is het betrouwbaar timen van dode verbindingen, het opnieuw tot stand brengen van sessies en het vrijgeven van vergrendelingen die door de oude sessie werden vastgehouden (aangezien de server misschien niet besluit dat hij dood is op hetzelfde moment dat de client dat doet). Een ander probleem is pakketverlies, wat leidt tot zeer trage bewerkingen, langlopende databasetransacties en de daaruit voortvloeiende problemen met de duur van de vergrendeling en het opschonen van transacties. Je zult ook allerlei krankzinnige en kapotte proxy's en firewalls tegenkomen onder de zon - proxy's die CONNECT ondersteunen maar dan blijkt dat al het verkeer HTTP's is en verminkt het als dat niet het geval is; firewalls met buggy stateful verbindingstracking die ervoor zorgen dat verbindingen mislukken of naar een halfopen zombiestatus gaan; elk NAT-probleem dat je maar kunt bedenken; carriers die "behulpzaam" TCP ACK's genereren om de latentie te verminderen, laat staan de problemen die worden veroorzaakt met het ontdekken van pakketverlies en de grootte van vensters; gekke poortblokkering; enz.
Omdat iedereen HTTP gebruikt, kun je verwachten dat dat werkt - in ieder geval veel vaker dan wat dan ook. Dit geldt met name nu veelvoorkomende websites de REST+JSON-communicatiestijl gebruiken, zelfs in mobiele web-apps.
U kunt uw webservice-oproepen ook schrijven om idempotent te zijn met behulp van unieke aanvraagtokens. Hierdoor kan uw app wijzigingsverzoeken opnieuw verzenden zonder bang te hoeven zijn dat deze twee keer een actie tegen de database uitvoert. Zie idempotence en idempotentie definiëren .
Serieus, JDBC vanaf een mobiel apparaat lijkt nu misschien een goed idee - maar de enige manier waarop ik het zou overwegen, zou zijn als de mobiele apparaten allemaal op een enkel zeer betrouwbaar wifi-netwerk zouden zijn onder mijn directe controle. Zelfs dan zou ik het om redenen van database performance management vermijden als ik dat zou kunnen. Je kunt iets als PgBouncer gebruiken om verbindingen tussen veel apparaten aan de serverzijde te poolen, dus pooling van verbindingen is geen groot probleem, maar het opschonen van verloren en verlaten verbindingen is dat wel, net als het tcp keepalive-verkeer dat nodig is om het te laten werken en de lang vastgelopen transacties van verlaten verbindingen.