none
Ways of creating WCF proxy RRS feed

  • Question

  • Hi,

    Need opinion or suggestion or recommendations for the below scenario which is working currently but believe that its a performance overhead or over designed.

    Synopsis of current implementation : 

    In our project we have 20 to 25 wcf services hosted in IIS with Federation binding and WSHttpBinding. To consume this WCF services from ASP.NET which is hosted in separate web server (both Webserver and App server are in same domain), the fallowing design implementation takes care of that:

    1. For each of the service need to create a proxy class using SVCUTIL.exe , and maintain those proxy classes in a assembly.

    2. In back end database, binding configuration along with endpoint information is being maintained for each of the 20 to 25 services.

    3. Whenever ASP.NET needs to use the service:

    a. will reference assembly which has list of proxy class created using SVCUTIL.exe.

    b. Will have mechanism to connect to database read the Binding configuration and endpoint information(which is in XML format) from database.

    c. Deserialize the Binding configuration and Endpoint information from XML, construct Federation Binding and WSHTTPBinding objects by code with deserialized information and create the proxy object.

    Observation: I felt that maintaining of binding and endpoint information in database and constructing proxy using this information is overhead each time.

    Instead their are two approaches : 

    1. use assemblies of WCF service and create proxy using Channel  Factory, providing endpoint and URL information of the WCF service.

    Challenges with the approach : maintaining of URL's hosted in APP server in ASP.NET code, which is more like a hard coding and tight coupling.

    2. Use service reference and use auto generated proxy of Visual studio.

    Challenges with the approach : maintaining those many listed URL's (20 to 25 wcf services) and their respective proxy class (which are auto generated is not a clean process).

    Would request to please go through the scenario and provide recommendations and correct me if their is anything wrong in understanding. 

    Would like to describe the scenario in much detailed manner in any other forms if required.

    Thanks,

    Prasanna

     

    Tuesday, January 21, 2014 4:47 AM

All replies

  • There are 3 basic ways to create a WCF client:

    1. Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.

    2. Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.

    3. Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.

    Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.

    Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.

    Thursday, January 23, 2014 10:05 AM
  • Yes, i read this stuff, i too believe that Option2 (as per your information) and Option1 listed in my post which is using of channel factory's by sharing the assemblies of service interface in the client side.

    However i was not aware of completely lose the content of HTTP errors in case of using WCF service with Federation binding and WSHttpBinding, can you please provide or share more references on this. The hyperlink shared gives information related to more of Rest full service.

    Also would you recommend using creation of channel factory approach  in case of Federation binding, i am not seeing any specific challenges though.

    Thanks

     
    Friday, January 24, 2014 4:49 AM
  • Also would you recommend using creation of channel factory approach  in case of Federation binding, i am not seeing any specific challenges though.

    Thanks.

     

    Use the ChannelFactory class with a known interface. This depends on you having local interfaces that describe the service contract. The big advantage is that you can change more easily.  But you still have to recompile and fix changes, but now you're not regenerating code, you're only referencing the  new interfaces. Channel factory is commonly used when you have control of both  the server and  the client.

    In  ChannelFactory<T> you must share contract assemblies between the service and the client.  That's why  ChannelFactory<T> can save you time. 

    When your project shares a common service contract DLL between the client and the server, you have to use  the ChannelFactory class.

    Friday, February 7, 2014 11:37 AM