Какая технология лежит в основе интерфейса ServiceAsync?

Question

Я разработал веб-приложение (работает должным образом), которое регистрирует пользователя в системе и позволяет пользователю загружать файл в систему через https. Код на стороне клиента полностью разработан с использованием GWT 2.4, а серверная часть состоит из нескольких сервлетов. За исключением кода загрузки, все коммуникации клиент-сервер осуществляются через интерфейс ServiceAsync, как это принято в GWT. Код загрузки основан на форме, напрямую связывающейся с сервлетом загрузки.

Этот проект разработан как курсовая работа, и мой профессор заинтересован в знании базовой архитектуры веб-инструментария Google, специально ориентированной на взаимодействие клиент-сервер. Его вопрос был

"Каким образом клиентский код знает URL-адрес сервера, чтобы все взаимодействие осуществлялось?"

Его вопрос правомерен для интерфейса ServiceAsync. Я вызываю функцию на стороне сервера, которая кажется ему интересной, и он хочет знать, что лежит в основе этого процесса.

Для загрузки я только что определил uploadForm.setAction(GWT.getModuleBaseURL()+"upload");, где upload - это имя сервлета загрузки в web.xml.

Я сказал ему, что компилятор генерирует код Javascript, который содержит весь код веб-приложения (вся система разрабатывается динамически), и URL-адрес сервлета помещается в этот файл сценария, однако ответ его не удовлетворяет. Пожалуйста, дайте мне знать внутренние факты взаимодействия клиент-сервер с GWT.

Пожалуйста, дайте мне несколько ответов, которые помогут моему профессору понять асинхронную связь RPC между клиентом и сервером GWT.

Answer 1

Базовая технология показана здесь в виде диаграммы. Google говорит"GWT предоставляет механизм RPC на основе сервлетов Java для обеспечения доступа к ресурсам на стороне сервера. Этот механизм включает в себя генерацию эффективного кода на стороне клиента и сервера для сериализации объектов в сети с использованием отложенного связывания . "

Клиент знает URL для запроса, потому что вы бы пометили свой интерфейс службы тегом @RemoteServiceRelativePath.Это связывает службу с путем по умолчанию относительно базового URL модуля.Этот URL-адрес находится там, где Javascript отправляет ваш запрос.

Существует гораздо больше информации о RPC GWT, если вы захотите, и вы можете начать выделять ее здесь и здесь .

Answer 2

Относительно основного вопроса о том, как клиент знает URL-адрес сервера, звучит так, будто профессор может задавать вопрос о полном URL-адресе сайта (доменном имени), а не только о подкаталогах служб.как они определены в @RemoteServiceRelativePath и в web.xml.

Что касается этого более фундаментального аспекта вопроса, я думаю, что «Политика одинакового происхождения» (SOP), которую браузеры используют для обеспечения безопасности javascript, может быть важной частью ответа.Это объяснено в одном из часто задаваемых вопросов GWT.Первое, что делает браузер на стороне клиента (после установления HTTPS-соединения, что, я думаю, могло бы стать еще одной важной частью ответа), - это чтение html-файла хоста, на который ссылается файл bootstrap nocache.js.После загрузки этого файла SOP гарантирует, что все последующие файлы приложения JS будут поступать с того же сервера, что и файл начальной загрузки и файлы html узла.Как только файлы приложения загружены, все происходит в этом контексте с определенными внутренними URL-путями, которые уже определены для RPC.

Answer 3

В GWt есть несколько способов привязать службу RPC к определенному URL. Во-первых, аннотация @RemoteServiceRelativePath, которая размещается на синхронном интерфейсе. Используя правило отложенного связывания, GWT обнаружит этот URL-адрес и автоматически установит его для экземпляра службы.

Второй - приведение экземпляра асинхронной службы GWT-RPC к ServiceDefTarget и установка URL-адреса вручную.

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