myslíte je to jednodušší a rychlejší to udělat s JDBC, protože nezohledňujete skutečné provozní prostředí telefonů a přenosných zařízení. Často mají flakey konektivitu přes buggy provoz přepisující proxy a šílené firewally. Obvykle používají síťovou transportní vrstvu, která má vysokou a proměnlivou ztrátovost paketů a latence, které se mění v mnoha řádech v krátkých časových rozpětích. TCP opravdu není v tomto prostředí skvělé a zvláště se potýká s dlouhotrvajícími připojeními.
Klíčovou výhodou webové služby je, že:
-
Má krátkodobá připojení s minimálním stavem, takže je snadné se vrátit tam, kde jste byli, když zařízení přepne sítě WiFi, do/z mobilní sítě, krátce ztratí připojení atd.; a
-
Dokáže projít všemi kromě těch nejstrašnějších a nejdrakoničtějších webových proxy
Budete pravidelně mít problémy s přímým připojením JDBC. Jedním z problémů je spolehlivé načasování mrtvých připojení, opětovné navázání relací a uvolnění zámků držených starou relací (protože server nemusí rozhodnout, že je mrtvé ve stejnou chvíli, kdy to udělá klient). Další je ztráta paketů způsobující velmi pomalé operace, dlouhotrvající databázové transakce a následné problémy s trváním uzamčení a úlohami čištění transakcí. Setkáte se také s nejrůznějšími šílenými a nefunkčními proxy a firewally pod sluncem – proxy, které podporují CONNECT ale pak se ukáže, že předpokládáme, že veškerý provoz je HTTPs, a pokud tomu tak není, zničí jej; firewally s chybovým sledováním stavových připojení, které způsobují selhání připojení nebo přechod do polootevřeného zombie stavu; každý problém NAT si dokážete představit; dopravci "pomocně" generují TCP ACK pro snížení latence, bez ohledu na problémy, které způsobuje zjišťování ztrát paketů a velikost okna; šílené blokování portů; atd.
Protože všichni používá HTTP, můžete očekávat, že to bude fungovat - přinejmenším mnohem častěji než cokoli jiného. To platí zejména nyní, kdy běžné webové stránky používají komunikační styl REST+JSON i v mobilních webových aplikacích.
Volání webových služeb můžete také napsat tak, aby byly idempotentní pomocí jedinečných tokenů požadavku. To umožňuje vaší aplikaci znovu odesílat požadavky na úpravu bez obav, že provede akci proti databázi dvakrát. Viz idempotence a definování idempotence .
Vážně, JDBC z mobilního zařízení by teď mohlo vypadat jako dobrý nápad – ale jediný způsob, jak bych o tom uvažoval, by byl, kdyby byla všechna mobilní zařízení v jediné vysoce spolehlivé WiFi síti pod mou přímou kontrolou. I tak bych se tomu vyhnul z důvodů správy výkonu databáze, pokud bych mohl. Můžete použít něco jako PgBouncer ke sdružování připojení mezi mnoha zařízeními na straně serveru, takže sdružování připojení nepředstavuje velký problém, ale vyčištění ztracených a opuštěných připojení je, stejně jako provoz tcp keepalive nutný k tomu, aby fungoval, a dlouho zablokovaný transakce z opuštěných připojení.