Переопределить адрес конечной точки службы WSDL, сгенерированный Glassfish

Question

У меня есть веб-сервис, сгенерированный wsgen через maven. Когда я развертываю сервис в Glassfish, он помещает URL-адрес сервера в WSDL. На нашем сервере Glassfish работает прокси-сервер Apache.

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

http://app server url/service...

вместо

http://proxy server url/service...

Я думаю, что мне нужно уточнить некоторые пункты...

1. Важен ли этот адрес конечной точки? Будут ли клиенты по-прежнему работать, если адрес конечной точки не совпадает с URL-адресом прокси-сервера, который они будут вызывать для вызова службы. Это в основном задает вопросы " является WSDL для веб-службы, как интерфейс для объекта ".

   ОБНОВЛЕНИЕ: В ответ на этот первый вопрос кажется, что " WSDL для веб-службы как интерфейс для объекта ". Адрес конечной точки, указанный в WSDL, не важен. Фактически, относительно тривиально вызвать операцию веб-службы на другой конечной точке, чем та, которая указана в WSDL, как описано здесь.

   // Создать сервис и прокси из сгенерированного класса Service.
   HelloService service = new HelloService ();
   HelloPort proxy = service.getHelloPort ();
   

   // Переопределить адрес конечной точки
   ((BindingProvider) прокси).getRequestContext(). Положим (BindingProvider.ENDPOINT_ADDRESS_PROPERTY, 
           " http://new/endpointaddress ");
   proxy.sayHello ("Привет, мир!");
   

2. WSDL генерируется автоматически при развертывании на Glassfish. Есть ли простой способ переопределить этот сгенерированный адрес конечной точки в Glassfish через настройку сервера приложений. Если это так, я могу создать параметр для автоматического размещения URL-адреса прокси-сервера в сгенерированном WSDL.

Если 1 действительно важен, и мы не можем переопределить его каким-либо образом с помощью 2, то это в основном означает, что нам нужно сделать отдельные сборки для разработки и производства. Это не кажется "правильным", так как мне кажется, что единственное, что нам нужно сделать для развертывания на другом сервере, это удалить существующую (и протестированную) войну из одной среды на новый сервер.

Answer 1

Оказывается, есть Server Name параметр на HTTP Listener где служба развернута. Вы можете указать это значение в консоли администрирования Glassfish, и Glassfish будет использовать это имя, а не имя хоста в URL-адресе запроса.

К сожалению, этот параметр не позволит вам переопределить порт или протокол (от http до https), если ваш сервер приложений и прокси-сервер не используют одни и те же (у нас это не так).

Вместо этого я написал простой фильтр сервлетов для моего сервиса, чтобы справиться с этим для меня.

Answer 2

Я обнаружил, что я считаю очень простым способом решения этой проблемы: используйте mod_substitute в Apache. Так как те из нас, у кого есть эта проблема, уже используют Apache, и он встроен и прост, мне больше понравился этот подход.

Я поместил блок, похожий на приведенный ниже, в один из моих файлов Apache conf и нашел радость:

<Location />
   AddOutputFilterByType SUBSTITUTE text/xml
   Substitute "s|http://internal:8080/xxx|https://external/xxx|ni"
</Location>