Ответ 1
Вы считаете, что проще и быстрее делать это с JDBC, потому что вы не рассматриваете реальную операционную среду в мире телефонов и портативных устройств. Они часто имеют плохую связь через багги, переписывающие прокси и безумные брандмауэры. Обычно они используют сетевой транспортный уровень, который имеет высокие и переменные скорости потери пакетов и задержки, которые изменяются на многие порядки в короткие промежутки времени. TCP действительно невелик в этой среде и особенно борется с долгоживущими подключениями.
Ключевым преимуществом веб-службы является то, что она:
-
Имеет короткоживущие соединения с минимальным состоянием, поэтому легко вернуться к тому месту, где вы были, когда устройство переключает сети Wi-Fi, в/из сотовой связи, ненадолго теряет связь и т.д.; и
-
Может пройти через все, кроме самых ужасных и драконовских веб-прокси.
У вас будут проблемы с прямым соединением JDBC. Одной из задач является надежное выключение мертвых соединений, повторное установление сеансов и освобождение блокировок, хранящихся в старой сессии (так как сервер не может решить, что он мертв одновременно с клиентом). Другим является потеря пакетов, вызывающая очень медленные операции, длительные транзакции базы данных и связанные с ними проблемы с продолжительностью блокировки и задачами очистки транзакций. Вы также встретите всевозможные безумные и сломанные прокси-серверы и брандмауэры под прокси-серверами sun, поддерживающими CONNECT, но затем убедитесь, что весь трафик - это HTTP-сообщения и калечат его, если это не так; брандмауэры с ошибкой отслеживания состояния с ошибкой, которые вызывают сбои подключения или переходят в полуоткрытое состояние зомби; каждая проблема с NAT, которую вы можете себе представить; носители "полезно" генерируют TCP ACK для уменьшения латентности, не обращая внимания на проблемы, которые возникают при обнаружении потери пакетов и определении размера окна; блокировка порталов; и др.
Поскольку каждый использует HTTP, вы можете ожидать, что он будет работать - по крайней мере, намного чаще, чем что-либо еще. Это особенно актуально сейчас, когда обычные веб-сайты используют стиль общения REST + JSON даже в мобильных веб-приложениях.
Вы также можете написать свои вызовы веб-сервисов, чтобы быть идемпотентными, используя уникальные маркеры запросов. Это позволяет вашему приложению повторно отправлять запросы на модификацию, не опасаясь, что он дважды выполнит действие против базы данных. См. idempotence и определение идемпотенции.
Серьезно, JDBC с мобильного устройства теперь может показаться хорошей идеей, но единственный способ, который я бы даже подумал, - это, если бы мобильные устройства были в одной сети с высокой надежностью WiFi под моим прямым контролем. Даже тогда я мог бы избежать этого по причинам управления эффективностью базы данных, если бы мог. Вы можете использовать что-то вроде PgBouncer для объединения соединений между многими устройствами на стороне сервера, поэтому объединение пулов не является большой проблемой, но очистка потерянных и оставленных соединений, равно как и постоянный трафик tcp, необходимый для его работы, и длительный останов транзакции из заброшенных соединений.