Веб-сервис против TCP / IP-сокетов (Java) + SQL-соединения

Question

В настоящее время мы находимся на этапе жизненного цикла нашего продукта, когда думаем о переходе на веб-службы. Наша система написана на Java, которая состоит из ряда клиентских и серверных приложений, которые общаются друг с другом через TCP-сокеты, а также имеют встроенный SQL для выполнения поиска и обновления данных (yuk! Я знаю), который использует наш собственный класс SQL Connection. который затем использует java.sql.Connection для подключения к базе данных SQL Server с помощью драйвера Microsoft JDBC.

Приложения связываются друг с другом с помощью сокетов TCP. Они запрашивают данные и передают данные друг другу. Который прекрасно работает.

Мысль

Итак, мы смотрим на преобразование всего доступа к данным и связи TCP в веб-службу.

Веб-сервис будет предназначен для работы на защищенном интернет-сайте компании. Идея заключается в том, чтобы пользователи могли подключать своих клиентов к веб-сервису из дома - когда они не находятся в сети компании - или на работе, когда они есть.

Клиентские приложения будут отправлять / получать сообщения в / из серверных приложений, используя веб-сервис. Клиентские приложения будут получать и обновлять данные в базе данных с помощью веб-службы.

Вопрос

Я просто хотел бы знать, что люди испытывают, когда делают что-либо с двухсторонней связью (запрос и передача) через веб-сервис (если это возможно) и что думают по этому поводу.

Преобразование доступа к данным в веб-службу кажется достаточно простым - я могу предвидеть некоторые проблемы с производительностью, когда большие наборы данных извлекаются в некоторых частях системы.

Я просматриваю различные материалы для чтения по этому вопросу, так как я уже давно обращаюсь к веб-сервисам (используя C # и ASP.NET). В настоящее время читаю «Создание Web-сервисов с Java ™: понимание XML, SOAP, WSDL и UDDI». Должен признать, я думал, что веб-сервисы всегда были без сохранения состояния, но только что прочитали, что это не так!

Спасибо

Andez

Answer 1

Помогает думать, что веб-сервисы такие же, как и любое другое веб-приложение на транспортном уровне.Он использует протоколы HTTP / HTTPS таким же образом, просто вместо того, чтобы отправлять HTML, он отправляет XML в соответствии с предопределенным форматом (SOAP).Таким образом:

• Он ориентирован на запрос / ответ
• Может быть с сохранением состояния так же, как веб-страница с состоянием с использованием сеансов (при условии, что у вас есть клиент веб-службыкоторый поддерживает сохранение файлов cookie сеанса между запросами)
• Все запросы в конечном итоге сводятся к старым добрым конечным точкам сервлета на сервере

Помня об этих ограничениях и функциях, подумайте о своих требованияхи как они сопоставляются друг с другом.Если вам нужна настоящая двусторонняя связь (push), то веб-сервисы не идеальны.Они ориентированы на клиент / сервер, на запрос / ответ.Толчок достижения, вам придется опросить от клиента.Возможная альтернатива может заключаться в том, чтобы позволить и «серверу», и «клиенту» действовать как «серверы» веб-службы.Это означало бы связывание некоторого облегченного движка сервлетов с клиентом (например, Jetty), чтобы «сервер» мог делать вызовы веб-службы «клиенту».Другой способ - взглянуть на двусторонний RMI / IOOP.

Еще один способ - сохранить коммуникационный уровень таким, какой он у вас сегодня.Не существует неотъемлемой выгоды рефакторинга для веб-сервисов только ради использования веб-сервисов.Если они не добавляют никакой выгоды, это просто трата.Как вы уже упоминали, Web-сервис содержит множество дополнительных накладных расходов (подробный протокол, механизм сервлетов и т. Д.), Поэтому ему действительно необходимо сбалансировать дополнительные затраты и время разработки с явным преимуществом.Как говорится, «если он не сломан, не чини».Как вы говорите, текущее решение «отлично работает», я бы, наверное, не изменил его.Это только я, хотя.