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

Question

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

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

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

вместо того , чтобы

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

Я предполагаю, что мне нужно некоторое разъяснение по нескольким пунктам...

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

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

   // Create service and proxy from the generated Service class.
   HelloService service = new HelloService();
   HelloPort proxy = service.getHelloPort();
   

   // Override the endpoint address
   ((BindingProvider)proxy).getRequestContext().put(
           BindingProvider.ENDPOINT_ADDRESS_PROPERTY, 
           "http://new/endpointaddress");
   proxy.sayHello("Hello World!");
   

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

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

Answer 1

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

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

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

Answer 2

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

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

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