Относительное мыло WSDL: адресное местоположение

Могу ли я иметь расположение мыла: адрес в WSDL относительно местоположения WSDL или, по крайней мере, относительно сервера? Например, я хочу написать:

<soap:address location="https://exampleserver.com/axis2/services/ExampleService" />

as:

<soap:address location="/axis2/services/ExampleService" />

Это позволит ускорить развертывание на нескольких серверах, например, на тестовых серверах. Кроме того, в случае с осью 2c, если я хочу, чтобы моя служба использовалась как из HTTP, так и для HTTPS, жизнь становится сложнее для разработчиков, использующих мою службу, поскольку они не могут просто импортировать WSDL из нее по умолчанию "WSDL".

Ответы

Ответ 1

WSDL описывает клиентам форматы, типы, параметры и т.д., необходимые для взаимодействия с веб-службой. Затем они используются такими инструментами, как WSDL2C для генерации кода, необходимого для взаимодействия.

Но даже если вы предоставляете свою услугу по HTTP или HTTPS, код-заглушка клиента будет таким же. Вы не восстанавливаете свои клиентские заглушки для каждого адреса конечной точки. Клиент остается неизменным, он меняет точку доступа.

Этот адрес не должен быть жестко закодирован в сгенерированном клиентском коде, он должен быть настраиваемым URL-адресом внутри клиентского приложения.

Конечно, у вас есть URL-адрес, указанный внутри WSDL, и это неприятно, когда вы развертываете свой веб-сервис на сервере dev, а затем выполняете этап и затем в производство. Конечные точки будут разными в каждой среде (возможно, они умножаются на 2 для HTTP + HTTPS), но на данный момент ваши разработчики не пострадают, потому что вы не обновляете код.

Когда дело доходит до доступа к веб-службе, у вас все равно будут разные адреса (для dev, промежуточных и prod-серверов), даже если они будут относиться к чему-то или абсолютному. Поэтому я не вижу, как полезно иметь относительный адрес внутри WSDL, поскольку вам все равно нужно управлять точками доступа в конфигурации клиента.

Ответ 2

Существует два способа получения WSDL.

Один, где подается жестко закодированный wsdl, например:

https://hostname/contextname/services/myAPIService/myAPI.wsdl

и другой, где выполняется сгенерированный wsdl, например:

https://hostname/contextname/services/myAPIService?wsdl

Если вы используете динамическую опцию, он будет использовать этот код:

req.getRequestURL().toString();

чтобы получить URL-адрес, который будет использоваться в сгенерированном WSDL. Этот код находится в классе ListingAgent (в пакете org.apache.axis2.transport.http).

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

Одна из проблем, которые я обнаружил с динамическими параметрами, заключается в том, что если в исходном WSDL в местоположении используется HTTP, то в сгенерированном он все равно будет использовать HTTP, даже если вы использовали HTTPS для доступа к нему. (Это происходит в версии 1.5, которая используется моим проектом)

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

Ответ 3

После длительного поиска я почти уверен, что атрибут soap:address location должен быть абсолютным URL-адресом. Это усложняется, если вы работаете с разными средами, такими как разработка, тестирование и производство.

Возможно, обходным путем было бы прочитать на стороне клиента первую часть URL-адреса из файла конфигурации (например, https://exampleserver.com) и конечную часть из WSDL (например, /axis2/services/ExampleService) и объединить их для сборки абсолютный путь. Первый позволит вам переключаться между средами.