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

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

5 голосов
/ 27 января 2010

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

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

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, 
        "<a href="http://new/endpointaddress" rel="nofollow noreferrer">http://new/endpointaddress</a>");
proxy.sayHello("Hello World!");

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

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

Ответы [ 2 ]

5 голосов
/ 29 января 2010

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

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

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

4 голосов
/ 09 августа 2013

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

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

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