使用ChannelFactory调用wcf服务的好处是什么

Question

if i know the service url then i can click on add reference and add the service url to create proxy at client side to consume it but without creating proxy at client side we can consume and call service with the help of ChannelFactory.

so i like to know when people will go to use ChannelFactory to create proxy at runtime and what is the advantage?

if i want that if other people know my service url then also they will not be able to add my service as add service reference....how to enable this feature? i want other people will not be able to create proxy at their end if they know my service url....is it possible. i want that people always has to call ny service using ChannelFactory. please discuss this issue in details. thanks

Answer 1

I've used the ChannelFactory instead of the autogenerated proxies to use the same object model on the server side and on the client. Also here Sharing Interfaces Between a WCF Service and Client (marked w/ ServiceContract) some problems with autogenerated proxies are discussed.

As for the hiding metadata, the answer is probably here How to hide wsdl information on WCF?

Answer 2

I usually create two assemblies, one with the service metadata (Interfaces [service contracts] and data objects [datacontracts]) and one with the actual service implementation.

Usually i self-host wcf services and skips the DataExchange endpoint-service needed for clients that dont have the meta data (to create proxy's). Clients receive my meta data dll and write their own proxies or uses a custom library together with the metadata dll to create a proxy. Both approaches uses the channelfactory to create the proxy. If a service is used in a LAN environment I typically setup a discovery service so that clients can find the service url(s) for a specific service interface (custom library code).

Maybe Im just old-school but I like to have control over the process. Versioning concerns etcetera. Another reason, when there is more than one way to use a technology, I focus on the one that can learn me the most about it.

Maybe you should use IIS and service pages (SVC) and auto-proxy creation in Visual Studio if you want to quickly test a service or isn't comfortable with the WCF programming model. Use Channelfactory if you write your own service libraries and need more fine-grained communication control (common service discovery strategy, common configurations/common binding settings, common security settings, hooking into events in the communication stack to run custom code, etcetera).

Answer 3

If you have any clients who are not .NET (like Java or PHP, for example), ChannelFactory won't work for them as that is specific to .NET and WCF. In that case, you'll either have to publish the metadata or send the client a WSDL so they can create the proxy via whatever means their language of choice uses (I don't know much about Java, PHP, etc so I can't say much more than that definitively).

As for using ChannelFactory , I assume you're talking about ChannelFactory<T> , as ChannelFactory itself is an abstract class and can't be instantiated. Using the channel factory gives a greater degree of control (as others have indicated) - for ChannelFactory<T> the client will need the service contract (interface, not the implementation), so either using a common assembly shared by everyone or providing the interface to the clients are the two easiest ways to achieve this.

You can disable publishing metadata (the WSDL) by turning httpGetEnabled to "false" in your config file in the <serviceMetadata> tag:

<system.serviceModel>
  <behaviors>
    <serviceBehavior>
      <behavior name="MyServiceBehavior">
        <serviceMetadata httpGetEnabled="false" />
      </behavior>
    </serviceBehavior>
  </behaviors>
</system.serviceModel>

You would then reference this behavior by setting the endpoint element's behaviorConfiguration attribute to "MyServiceBehavior".

You should also remove any mex endpoints as (based on my understanding) that's a newer way for web services to expose their metadata. If the metadata is not exposed, then clients cannot construct the proxy via the WSDL and will have to do so by some other method. .NET clients specifically will not be able to use Add Service Reference.

Finally, if you're concerned about access to your service, you should really implement some sort of authentication scheme. If you just simply want to disable publishing (exposing) metadata then setting httpGetEnabled to false and removing any mex endpoints should do the trick.