Injecting an unrelated contract into the WSDL created by WCF's MEX provider

Question

I am implementing a WCF service (Contract A) that will eventually make calls to a standalone service (Contract B) hosted by the client. At design-time when the client queries my service's WSDL to build its proxy, I'd like to include the WSDL for Contract B so the client can build its service around that. Unfortunately, I can't figure out how to inject Contract B into the WSDL emitted by the service. Since the contract is an interface and doesn't have the [DataContract] attribute I can't add it as a known type. Is there any other way to inject a contract into emitted WSDL?

Here's an example:

[ServiceContract]
public interface IServerService
{
  [OperationContract]
  void GiveTheServerMyServiceUri(string uri);

  [OperationContract]
  void TellAllClientsSomething(string message);
}

// THIS IS THE INTERFACE I WANT TO INCLUDE IN THE WSDL
[ServiceContract]
public interface IClientService
{
  [OperationContract]
  void ReceiveMessageFromServer(string message);
}

public class ServerService : IServerService
{
  private List<string> knownClients;

  public void GiveTheServerMyServiceUri(string uri)
  { 
    knownClients.Add(uri);
  }

  public void TellAllClientsSomething(string message)
  {
    foreach (string clientUri in knownClients)
    {
      // 1. Create instance of ClientServiceProxy using client's uri
      // 2. Call proxy.ReceiveMessageFromServer(message)
    }
  }
}

At first it seems that this is a textbook example of a duplex contract. However, for this particular application, for a variety of reasons, I need a bit more separation between client and server so I was hoping to just give the client an interface to implement (via the WSDL), let it host its own service, then just tell me the service's url.

Answer 1

I don't see that this makes sense. Unless your service is implementing the service contract of the other service, then don't do this.

On the other hand, your service can implement the other service contract, and become a client to the other service. It can then delegate calls to the other service contract to that other service.

---

I just tried this to make sure. I created a new WCF Service library project. This created a Service1 implementing IService1, with two operations. I modified the [ServiceContract] attribute to use a specific namespace (http://localhost/service1).

I then added a new service, which gave me Service2, implementing IService2, with a single operation (DoWork). I updated the [ServiceContract] to use http://localhost/service2/.

I then updated Service1 to implement IService2 as well as IService1, and to delegate IService2.DoWork to the Service2 service. I did also have to add a new endpoint implementing IService2, and I had to specify a relative address, so that the two would not conflict (since they were in the same project). Here's the result:

using System;

namespace WcfServiceLibrary1
{
    public class Service1 : IService1, IService2
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }

        public CompositeType GetDataUsingDataContract(CompositeType composite)
        {
            if (composite.BoolValue)
            {
                composite.StringValue += "Suffix";
            }
            return composite;
        }

        public void DoWork()
        {
            Service2Reference.IService2 svc = null;
            try
            {
                svc = new Service2Reference.Service2Client();
                svc.DoWork();
            }
            finally
            {
                if (svc != null)
                {
                    ((IDisposable)svc).Dispose();
                }
            }
        }
    }
}