Kirk Evans Blog

.NET From a Markup Perspective

Call Web Service Proxies via Reflection

Call Web Service Proxies via Reflection

  • Comments 7

I received an odd question from a mailing list that I am on.  The poster wanted to iterate through the Web References for the current project and call a method that appears on each endpoint.  The first thing that popped into my mind was, "Why does every single endpoint that you reference have the same method?!?"  That means there is an early bound reference to multiple endpoints, where each endpoint shares the same method... I absolutely cannot think of a use case where this seems justifiable. 

The code to do this is pretty simple, I just use reflection to locate the types in the current assembly, determine if the type derives from SoapHttpClientProtocol, and calls the method.  More an interesting demo of reflection than a usable piece of code.  Interesting, just not applicable.


System.Reflection.Assembly a = System.Reflection.Assembly.GetExecutingAssembly();
foreach(System.Type type in a.GetTypes())
  object proxy = a.CreateInstance(type.FullName,false);
  MethodInfo mi = proxy.GetType().GetMethod("HelloWorld");
  string ret = Convert.ToString(mi.Invoke(proxy,new object[0]));


  • Wouldn't it be a better solution to define an interface for the method(s), and implement that interface in each proxy? (Assuming of course that he has control over the proxy code, or can at least subclass them)

    As far as use cases - one I can think of is a service broker/router that accepts messages and forwards them to one of multiple identical endpoints. I suppose if you wanted to construct such a broker in a highly flexible manner, you may want to use runtime discovery like this.
  • Cool I was wondering the same myself.

    Use Case for it.
    Global Fortune 500 Company Multiple Data centers, one in Asia, one in Europe. and one in Belgium. Why the one in Belgium by itself for only one plant, customer contract. Must have redundancy in the in case network cloud where to somehow go out, must still ship parts hourly so not Architecturally the best thing, customer mandated. This to us is nothing new. Different customers require different things. We still use one system at the back end for things like Financial roll ups and so on but we have to go out and get all this data regularly from all over the world.
  • Sometimes people do not want to have Web References at all ... and just point their code at the WSDL (aka dynamic web service proxy). There is help ;)
  • I don't think the router scenario fits here. Ideally, a router would have a mechanism to dynamically discover and bind endpoints, such as UDDI or WS-Discovery, and the routing would likely occur without a static design-time binding via a web reference. And a problem with the redundancy case is that you cannot easily add new endpoints... should you add a third or fourth failover endpoint, you would have to add a new web reference and code it.

    Another approach is to dynamically change the Url property of the proxy, therefore having only 1 proxy. If each of the endpoints shares a common subset but each extends with a new set of methods, then consider creating a proxy class by hand. Each proxy endpoint would then derive from this specialized proxy and provide the additional methods it needs.

    The combination of using a directory for discovery such as UDDI and dynamically creating proxies seems like a much better approach than statically binding "n" number of proxies where they only differ by the endpoint Url.
  • I would rather go to a lookup in UUDI and change dynamically the url of the generated proxy.
  • One of the promises of web services is that you can dynamically discover new services and invoke them. ...
  • One of the promises of web services is that you can dynamically discover new services and invoke them.

Page 1 of 1 (7 items)
Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post
Translate This Page