WCF:: ServiceHost & AddServiceEndpoint: Are Arguments types reversed?

Question

While I am trying to learn WCF, and it seems straight-forward enough, I came through an odd situation...at least it seems odd to me.

Why is it that the ServiceHost ctor takes a concrete class, and the AddServiceEndpoint takes the Interface, and not vice versa? it seems the latter is more logical from an OOP standpoint.

Consider the following:

    [ServiceContract]
    interface IVocalAnimal
    {
     [OperationContract]
     string MakeSound();
    }
  ...      
  public class Dog : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Woof!");
     }
  }
 ...
 public class Cat : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Meeooow!");
     }
  }

So now we wanto create an "AnimalSound" service that you can connect to get the sound of a Dog or a Cat via /AnimalSoundService/Dog or /AnimalSoundService/Cat

...
Uri baseAddress = new Uri("net.pipe://localhost/AnimalSoundService");
ServiceHost serviceHost = new ServiceHost(typeof(IVocalAnimal), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Dog), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Dog");
serviceHost.AddServiceEndpoint(typeof(Cat), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Cat");
...

But the above code will not compile as for some reason(s) I don't quite understand, the ServiceHost ctor wants the concrete class (so either Dog or Cat) and the EndPoint wants the Interface.

So what is the reason it is not vice-versa as it seems to me more natural that the finer granularity endpoint supports a specific implementation (so you could hit specific implementations of the contract per endpoint address) while the more general ServiceHost should be the one to accept the interface?

Btw, I am not being pedantic..I am just honestly trying to understand as I am sure it is I that missed something here.

Answer 1

When you create the ServiceHost, you are creating the actual service, so it must be concrete.

Your endpoints, on the other hand, are what your clients see. You don't necessarily want your clients to know your implementation -- they should just get the interface definition.

The endpoind DOES support a specific implementation, as you say: whichever one you use when you create the ServiceHost. The purpose of endpoints, is not to provide multiple implementations, but to provide multiple protocols/bindings to access a single implementation.

If you want distinct Dog and Cat services, I believe you'll need two ServiceHosts, each with one NetNamedPipeBinding endpoint.

Answer 2

I see what you thinking. From an OOP perspective it makes sense, but that's not a service perspective. A service is a group of operations. That group of operations is defined in a contract. You can use classes to model service contracts, but most use interfaces because interfaces are a more direct model. MSDN has a very good discussion of those concepts.

Remember, you don't know me and I don't know you. We exchange messages, not objects. I don't want cats and dogs from you. I would not know what to do with a cat or a dog you gave me unless we have prior agreement. You tell me what I can do and I call methods on you to do it. Here's a good article on data on the inside versus data on the outside.

Answer 3

I have to disagree a bit with the other answers. While they are technically correct in a way, I feel the most important reason for this to be the way it is has little to do with hiding the implementation or using classes vs interfaces to define service contracts.

It's a lot more obvious why it is the way it is if you take into account the fact that a single service implementation can expose multiple endpoints. Each endpoint might, or might not, expose a different contract, and each one could be exposed on a different binding, for all you know.

For example, you might have a service that exposes a one-way contract over MSMQ and a two-way contract over HTTP. Or perhaps it exposes a JSON contract on one URL and an XML one on another.