When developing using web services, we tend have different endpoint URLs for development, test and production. When developing Java EE apps, the best practice is to separate environment configuration from the application to the deployment process (a pattern I rarely see in practice unless already architected in like ).
In terms of is when I see an application try to manage the connections to the web services rather than letting the container do it. For an application to manage web services, it needs to ensure endpoint URIs, timeouts, certificates, security and perhaps a whole other slew of tuning options that may be needed on production deployments. In addition, it would mean that part of the application code would may need to know credentials to access the web service which would mean application specific methods of retrieving that data.
WebSphere Application server provides a web GUI along with scripting to manage all of this. Other application servers would also have their own methods of supporting these deployment issues preventing the application from actually managing it.
This is enabled simply by using the @WebServiceRef annotation pointing to a generated @WebService class. The @WebService class is generated from a WSDL that is generated using wsimport from a known endpoint.
Once you do that it’s all set and application servers can be configured to change the endpoint or do tunings for timeouts and other connection properties.