Relative WSDL soap:address location

Can I have the soap:address location in a WSDL relative to the WSDL location, or at least relative to the server? For instance I want to write:

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

as:

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

This would enable faster deployment to multiple servers, like test servers. A开发者_开发百科lso, in the case of axis2c if I want my service to be used both from HTTP or HTTPS life becomes harder for developers using my service as they can't simply import the WSDL from it's default location "?WSDL".

The WSDL describes to clients the message formats, types, parameters etc needed to interact with the web service. This is then used by tools like WSDL2C to generate the code needed for the interaction.

But even if you expose your service on HTTP or HTTPS, the client stub code will be the same. You don't regenerate your client stubs for each endpoint address. The client stays the same, it's the access point that changes.

This address should not be hardcoded in the generated client code, it must be a configurable URL inside the client application.

Sure, you have an URL specified inside the WSDL and it's a nuisance when you deploy your web service in the dev server, and then to staging and next into production. The endpoints will be different in each environment (maybe multiplied by 2 for HTTP + HTTPS) but at this point your developers are not affected because you don't regenerate the code.

When it comes to access the web service, you would still have different addresses (for dev, staging and prod servers) even if it would be relative to something or absolute. So I don't see how it is helpful to have relative address inside the WSDL since you still have to manage the access points into the client configuration.

There are two ways of getting the WSDL.

One where a hard-coded wsdl is served, for example:

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

and another one where a generated wsdl is served, for example:

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

If you use the dynamic option it will use this code:

req.getRequestURL().toString();

to get the URL that will be used in the generated WSDL. This code is in the class ListingAgent (in the package org.apache.axis2.transport.http).

From what you mentioned in your question if you want to have relative location it must be because you want to use it in multiple servers, so you would need to use the dynamic option.

One problem I found with the dynamic options is that if in the original WSDL the location is using HTTP, then in the generated one it will still use HTTP even if you have used HTTPS to access it. (This happens in version 1.5 which is the one my project is using)

Another problem is if you are using a load balancer, because the generated WSDL will be generated with the location of the final server instead of the balancer. An option for this would be to extend the classes AxisServlet and ListingAgent to replace the code mentioned above.

After a long search I'm almost sure that soap:address's location attribute has to be an absolute URL. This gets things more complicated if you work with different environments, such as development, test and production.

Maybe a workaround would be to read, on the client side, the first part of the URL from a config file (e.g. https://exampleserver.com) and the final part from the WSDL (e.g. /axis2/services/ExampleService) and combine them to build an absolute path. The former will allow you to switch among environments.