The entire point of WSDL is to allow automatic code generation. The automatically generated code allows a developer to make calls to a webservice as if it were a local call. Many generators (including wsdl2java) embed the endpoint into the client stubs (the same endpoint that is specified in the WSDL). Of course in the case of wsdl2java, one can edit that generated code and make the endpoint reflect the real location. And I believe that there are calls that can be made in .Net to change the endpoint. However your best bet is to have the WSDL reflect the true location of the endpoint.
Another option is to have Axis generate the wsdl for you (https://www.experian.com/services/SomeService?wsdl). The caveat of this is that Axis embeds the url retrieved from the last get operation. This works fine in many instances, however if you have a proxy or a server farm, https://www.experian.com/services/SomeService will look instead like https://10.15.6.134/services/SomeService (in other words it will use an internal IP address because that was the last address used to get the WSDL). Perhaps the Axis group can fix this (or has fixed this) with a configuration parameter. That let's you specify what host name to use when generating WSDL. For the time being, we provide Axis with a hand-coded WSDL file that provides the correct endpoint address. So basically, if you want to give people the opportunity to automatically generate client stubs using their tool of choice, you should place the correct endpoint in the WSDL. -----Original Message----- From: Sheptunov, Bogdan [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 2:14 PM To: [EMAIL PROTECTED] Subject: value of soap:address attribute Hello, I am trying to determine what the value of (wsdl)soap:address attribute should be, and to what extent that value is supposed to reflect the real URL at which the corresponding service is avaliable. In a WSDL, the following sample section describes a service itself: <wsdl:service name="SomeService"> <wsdl:port name="SomePort" binding="impl:SomeBinding"> <wsdlsoap:address location="http://companyname.com/services/SomeService"/> </wsdl:port> </wsdl:service> Until today, the value I've been putting in the wsdlsoap:address attribute looked like http://companyname.com/services/SomeService , and in fact the service was available at a different address (for instance, https://projectname.companyname.com/services/SomeService) Notice that both domain name and protocol are different. This served fine for me, since I have dev/staging/production enviroments deployed at different domains, and some of them do not require SSL. Having a single fake URL in wsdlsoap:location allowed me to have a single WSDL for all different environments. In addition, neither of SOAP request or response in fact contain the wsdlsoap:address URL. One of the users, however, has recently complained that the WSDL is incorrect because the endpoint value is fake, and that only by having wsdlsoap:address attribute pointing at a real physical service endpoint that user could connect to it. The only description for the this element I could find in the WSDl spec was this: "The SOAP address binding is used to give a port an address (a URI). A port using the SOAP binding MUST specify exactly one address. The URI scheme specified for the address must correspond to the transport specified by the soap:binding." My question is, shall the value of that attribute reflect the actual endpoint URL? What about the protocol (http/https)? It kind of makes sence that it would on one hand; on the other, I think that aside from the inconviniences described above it might create a conflict of responsibilities: WSDL, that is supposed to be designed by a developer and describe in what way what services can be accessed, would contain a concrete deployment endpoint that is up to the IS to define and maintain? With Axis 1.2, I dont see any effect the value of wsdlsoap:address has on service accessibility or speficics of accessing it. What am I missing? Should a real endpoint be placed into WSDL? Some of the client SOAP tools seem to attempt to use the soap:address tag value as the endpoint URL; is that a valid point? Thanks Bogdan
