Tu pensi è più semplice e veloce farlo con JDBC perché non stai considerando l'ambiente operativo del mondo reale di telefoni e dispositivi portatili. Spesso hanno una connettività debole attraverso proxy di riscrittura del traffico buggato e firewall folli. In genere utilizzano un livello di trasporto di rete con tassi di perdita di pacchetti elevati e variabili e latenze che variano su molti ordini di grandezza in brevi lassi di tempo. Il TCP non è davvero eccezionale in questo ambiente e in particolare lotta con connessioni di lunga durata.
Il vantaggio principale di un servizio web è che:
-
Ha connessioni di breve durata con uno stato minimo, quindi è facile tornare dove eri quando il dispositivo cambia rete WiFi, da/verso cellulare, perde brevemente la connettività, ecc.; e
-
Può passare attraverso tutti i proxy web tranne i più orribili e draconiani
Lo farai di routine riscontrare problemi con una connessione JDBC diretta. Una sfida è il timeout affidabile delle connessioni morte, il ristabilimento delle sessioni e il rilascio dei blocchi mantenuti dalla vecchia sessione (poiché il server potrebbe non decidere che è morto nello stesso momento in cui lo fa il client). Un altro è la perdita di pacchetti che causa operazioni molto lente, transazioni di database di lunga durata e conseguenti problemi con la durata dei blocchi e le attività di pulizia transazionale. Incontrerai anche ogni varietà di proxy e firewall folli e rotti sotto il sole:proxy che supportano CONNECT ma poi si scopre che tutto il traffico è HTTP e lo si storpia se non lo è; firewall con monitoraggio della connessione con stato buggy che causano il fallimento delle connessioni o il passaggio a uno stato di zombi semiaperto; ogni problema NAT che puoi immaginare; vettori che generano "utilmente" ACK TCP per ridurre la latenza, non importa i problemi che causano il rilevamento della perdita di pacchetti e il ridimensionamento della finestra; stravagante blocco delle porte; ecc.
Perché tutti utilizza HTTP, puoi aspettarti che funzioni, almeno, molto più spesso di qualsiasi altra cosa. Ciò è particolarmente vero ora che i siti Web comuni utilizzano lo stile di comunicazione REST+JSON anche nelle app Web mobili.
Puoi anche scrivere le tue chiamate ai servizi web per essere idempotenti utilizzando token di richiesta univoci. Ciò consente alla tua app di inviare nuovamente le richieste di modifica senza temere che eseguirà un'azione sul database due volte. Vedi idempotence e definire l'idempotenza .
Seriamente, JDBC da un dispositivo mobile potrebbe sembrare una buona idea ora, ma l'unico modo in cui lo prenderei in considerazione sarebbe se i dispositivi mobili fossero tutti su un'unica rete WiFi ad alta affidabilità sotto il mio diretto controllo. Anche allora lo eviterei per motivi di gestione delle prestazioni del database, se possibile. Puoi usare qualcosa come PgBouncer per raggruppare le connessioni tra molti dispositivi sul lato server, quindi il pool di connessioni non è un grosso problema, ma lo è la pulizia delle connessioni perse e abbandonate, così come il traffico keepalive TCP necessario per farlo funzionare e il lungo periodo di stallo transazioni da connessioni abbandonate.
