WSDL and AXIS ADB

If I understand correctly in a WSDL document, we can say in simple terms that:

• portype section: can be compared to an interface in a OO
  language, and describes the operation offered by the service.

• binding section: specifies which protocols the operation can be accessed through
  (e.g. SMTP, HTTP, etc.).

• services section: indicates an endpoint for each of the bindings defined.

Please, correct me if I'm saying something wrong.

If that is correct, when we create a client using AXIS ADB and Eclipse EE integrated AXIS tools, why do we also need to supply an URL as the endpoint of the service when instantiating the stub?

MultiplierImplStub stub=newMultiplierImplStub("http://localhost:8080/ProductServer/services/MultiplierImpl");

Shouldn't the stub, which is automatically built parsing the WSDL of the service, already know what the endpoints are?

EDIT:

And why the endpoint specified in the client does not match any of the endpoints defined in the WSDL?

<wsdl:service name="MultiplierImpl">
<wsdl:port name="MultiplierImplHttpSoap11Endpoint" binding="ns:MultiplierImplSoap11Binding">
<soap:address location="http://localhost:8080/AxisTestProjectServer/services/MultiplierImpl.MultiplierImplHttpSoap11Endpoint/"/>
</wsdl:port>
<wsdl:port name="MultiplierImplHttpSoap12Endpoint" binding="ns:MultiplierImplSoap12Binding">
<soap12:address location="http://localhost:8080/AxisTestProjectServer/services/MultiplierImpl.MultiplierImplHttpSoap12Endpoint/"/>
</wsdl:port>
<wsdl:port name="MultiplierImplHttpEndpoint" binding="ns:MultiplierImplHttpBinding">
<http:address location="http://localhost:8080/AxisTestProjectServer/services/MultiplierImpl.MultiplierImplHttpEndpoint/"/>
</wsdl:port>
</wsdl:service>

Solution 1:

Good question! The stub knows what the endpoints are at the moment of its generation, but further down the road these endpoints may change, and you don't want to regenerate manually the stub all over again and redeploy it, but rather just change a configuration parameter in your application. Regenerating the stub at runtime with each service call is not a great idea either, I'm sure you'll agree.

Having the ability to supply the endpoint is handy for multiple reasons: Sometimes you do not have live access to the web service at implementation time and the WSDL is used as mutual agreement between teams on both sides before the work begins. The final URL will may be known at this time. Also, you may need to test on a different environment, prior to pre-production and production - this can easily happen with a touch in the configuration, instead of having different stubs and different logic in your application for each environment.

The endpoint in the WSDL is great for web service discoverability when the service is already in production, when changes of the endpoint are not expected to happen. It eases the process of new clients consuming the web service. But even then, it is good to treat the endpoint as a variable because of the added flexibility, just in case.