Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Binding to a specific implementation of a Web service at runtime

Could you provide a reference to documentation allowing me to bind to a specific implementation of a Web service at runtime within .NET? Can I use the use the WSDL tool to create a proxy at compile time and then alter the URL (and/or other attributes of the proxy) at runtime to access the specific implementation of the service? Would some other mechanism or toolkit be better suited to doing this? If it has any bearing on the answer I would like to be able to activate the Web services asynchronously.
First, let me answer the question of dynamically invoking a service endpoint at runtime. You can do this very easily by setting the URL property of the proxy class. This is a publicly accessible property exposed by the proxy's base class, System.Web.Services.Protocols.SoapHttpClientProtocol. It is initialized in the constructor as shown below, and you can override this before invoking any methods:

  public MyService() {
            this.Url = "http://localhost/MyService/service1.asmx";

I don't recommend you modify anything inside the proxy class - you should never edit automatically generated code if you can avoid it. This gives you the flexibility to regenerate the proxy, for example when new methods are added, without having to edit the proxy once again to the new URL endpoint. You may also invoke any methods exposed by this proxy, asynchronously, using the BeginXXX() and EndXXX() methods. Each Web service method can be accessed through its .NET proxy synchronously, or asynchronously. This example demonstrates how to invoke services asynchronously.

Getting back to the runtime selection of service endpoints, you should consider that these endpoints must match the proxy's Web service WSDL bindings. So, what this means is you can only set the URL property to endpoints that implement each method exactly as specified by the proxy's WebServiceBindingAttribute. Multiple services implementing the same WSDL binding are doing one of a few things:

1. They are an exact copy of the service, possibly for load-balancing services across multiple machines - therefore they are exposed on different endpoints but are semantically equivalent.

2. Using interface-based WSDL binding, multiple services are implementing a few methods, or all methods, of the same WSDL contract. For example, if an industry standard WSDL were to be designed that provides the namespace and message definitions that services should support, it is possible for more than one company to implement a common service binding for consistency. In this way, a single message could even be issued to service endpoints that are hosted by different companies. You can implement a single message (method) from a shared WSDL contract on your service, or even implement multiple messages (methods) from several shared WSDL contracts. I have an example of interface-based WSDL binding here.

The point is, you can modify the endpoint URL dynamically, but you need to understand the circumstances under which this is ok: that is, that the WSDL binding expected by the proxy, will be implemented by the service.

Dig Deeper on Topics Archive