One of the key improvements in WCF is the concept of multiple “endpoints” at a Service. Last week (when I was offsite with a customer) I had an interesting revelation. While we cover the “ABCs” of Indigo (Address + Binding + Contract == Endpoint) in every introductory talk, many users don’t fully grasp the flexibility multiple endpoint support offers. This is most acute with regards to hosting in IIS, when multiple endpoint support involves “URI space beyond the file”.

For example, let’s say I have an Image Download Service hosted at image.svc. For interop purposes I expose a BasicHttp endpoint. I also add a second endpoint that uses a binary encoding instead of text. I provide a relative address of “binary” to this endpoint for addressing purposes. In this case my interop endpoint is exposed as:
http://kennyw.com/vdir/image.svc

And the binary endpoint is addressible as:
http://kennyw.com/vdir/image.svc/binary

Yes, that’s “/binary” after the filename.

The relevant piece of config for such as service (assuming you have a “binaryHttpBinding” defined in your bindings section) looks like:

<system.serviceModel>
 <services>
  <service name="Microsoft.ServiceModel.Samples.ImageService">
    <endpoint address=""
              binding="basicHttpBinding"
              contract="Microsoft.ServiceModel.Samples.IImageService" />

    <endpoint address="binary"
              binding="binaryHttpBinding"
              contract="Microsoft.ServiceModel.Samples.IImageService" />
  </service>
 </services>
</system.servicemodel>