Du tænker det er nemmere og hurtigere at gøre det med JDBC, fordi du ikke overvejer det virkelige driftsmiljø for telefoner og bærbare enheder. De har ofte flakey forbindelse gennem buggy trafik omskrivning af proxyer og vanvittige firewalls. De bruger typisk et netværkstransportlag, der har høje og variable pakketabsrater og latenser, der varierer over mange størrelsesordener i løbet af korte tidsrum. TCP er virkelig ikke fantastisk i dette miljø og kæmper især med langvarige forbindelser.
Den vigtigste fordel ved en webtjeneste er, at den:
-
Har kortvarige forbindelser med minimal tilstand, så det er nemt at komme tilbage til hvor du var, da enheden skifter WiFi-netværk, til/fra mobil, mister forbindelsen kortvarigt osv. og
-
Kan passere gennem alle undtagen de mest forfærdelige og drakoniske webproxyer
Du vil rutinemæssigt støder på problemer med en direkte JDBC-forbindelse. En udfordring er pålidelig timeout for døde forbindelser, genetablering af sessioner og frigivelse af låse, som den gamle session holder (da serveren muligvis ikke beslutter, at den er død på samme tid, som klienten gør). En anden er pakketab, der forårsager meget langsomme operationer, langvarige databasetransaktioner og deraf følgende problemer med låsevarigheder og transaktionsmæssige oprydningsopgaver. Du vil også møde alle slags vanvittige og ødelagte proxyer og firewalls under solen - proxyer, der understøtter CONNECT men så viser det sig at antage, at al trafik er HTTPs og mangle det, hvis det ikke er det; firewalls med buggy stateful forbindelsessporing, der får forbindelser til at fejle eller gå til en halvåben zombietilstand; ethvert NAT-problem, du kan forestille dig; carriers genererer "hjælpsomt" TCP ACK'er for at reducere latens, ligeglad med de problemer, der forårsager med opdagelse af pakketab og vinduesstørrelse; skør portblokering; osv.
Fordi alle bruger HTTP, kan du forvente, at det virker - i hvert fald langt oftere end noget andet gør. Dette gælder især nu, hvor almindelige websteder bruger REST+JSON-kommunikationsstil, selv i mobile webapps.
Du kan også skrive dine webservicekald til at være idempotente ved hjælp af unikke anmodningstokens. Det lader din app gensende ændringsanmodninger uden frygt for, at den udfører en handling mod databasen to gange. Se idempotens og definering af idempotens .
Seriøst, JDBC fra en mobilenhed ser måske ud som en god idé nu - men den eneste måde, jeg overhovedet ville overveje, ville være, hvis alle mobile enheder var på et enkelt høj-pålideligt WiFi-netværk under min direkte kontrol. Selv da ville jeg undgå det på grund af styring af databasens ydeevne, hvis jeg overhovedet kunne. Du kan bruge noget som PgBouncer til at samle forbindelser mellem mange enheder på serversiden, så forbindelsespooling er ikke et stort problem, men oprydning af mistede og forladte forbindelser er, ligesom den tcp keepalive-trafik, der kræves for at få det til at fungere, og den er gået i stå. transaktioner fra forladte forbindelser.