Переопределение оконной службы WSDL с защитой от морщин

Question

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

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

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

вместо

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

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

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

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

    
   // 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, то это в основном означает, что нам нужно сделать отдельные сборки для разработки и производства. Это не «кажется правильным», как мне кажется, единственное, что нам нужно сделать для развертывания на другом сервере, - это отбросить существующую (и протестированную) войну из одной среды на новый сервер.

Answer 1

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

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

То, что я сделал, было write a simple servlet filter для моего обслуживания, чтобы справиться с этим для меня.

Answer 2

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

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

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