How to create a WCF web service within an ASP.NET application that can return instances of an interface as a transparent proxy

Question

My use-case:

• I already have a working ASP.NET application
• I would like to implement a new Web Service as part of that application
• I am supposed to use a WCF service (*.svc), not an ASP.NET web service (*.asmx)
• The service needs to have one operation, let’s call it GetInterface(), which returns instance of an interface. This instance must reside on the server, not be serialized to the client; methods called on that interface must execute on the server.

Here’s what I tried (please tell me where I went wrong):

• For the purpose of testing this, I created a new ASP.NET Web Application project called ServiceSide.

• Within that project, I added a WCF Service using “Add → New Item”. I called it MainService. This created both a MainService class as well as an IMainService interface.

• Now I created a new Class library project called ServiceWorkLibrary to contain only the interface declaration that is to be shared between the client and server, nothing else:

  [ServiceContract]
  public interface IWorkInterface
  {
      [OperationContract]
      int GetInt();
  }
  

• Back in ServiceSide, I replaced the default DoWork() method in the IMainService interface as well as its implementation in the MainService class, and I also added a simple implementation for the shared IWorkInterface. They now look like this:

  [ServiceContract]
  public interface IMainService
  {
      [OperationContract]
      IWorkInterface GetInterface();
  }
  
  public class MainService : IMainService
  {
      public IWorkInterface GetInterface()
      {
          return new WorkInterfaceImpl();
      }
  }
  
  public class WorkInterfaceImpl : MarshalByRefObject, IWorkInterface
  {
      public int GetInt() { return 47; }
  }
  

  Now running this application “works” in the sense that it gives me the default web-service page in the browser which says:

  You have created a service.

  To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:

  svcutil.exe http://localhost:59958/MainService.svc?wsdl
  

  This will generate a configuration file and a code file that contains the client class. Add the two files to your client application and use the generated client class to call the Service. For example:

• So on to the client then. In a separate Visual Studio, I created a new Console Application project called ClientSide with a new solution. I added the ServiceWorkLibrary project and added the reference to it from ClientSide.

• Then I ran the above svcutil.exe call. This generated a MainService.cs and an output.config, which I added to the ClientSide project.

• Finally, I added the following code to the Main method:

  using (var client = new MainServiceClient())
  {
      var workInterface = client.GetInterface();
      Console.WriteLine(workInterface.GetType().FullName);
  }
  

• This already fails with a cryptic exception in the constructor call. I managed to fix this by renaming output.config to App.config.

• I notice that the return type of GetInterface() is object instead of IWorkInterface. Anyone know why? But let’s move on...

• Now when I run this, I get a CommunicationException when calling GetInterface():

  The underlying connection was closed: The connection was closed unexpectedly.

How do I fix this so that I get the IWorkInterface transparent proxy that I expect?

Things I’ve tried

• I tried adding [KnownType(typeof(WorkInterfaceImpl))] to the declaration of WorkInterfaceImpl. If I do this, I get a different exception in the same place. It is now a NetDispatcherFaultException with the message:

  The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:GetInterfaceResult. The InnerException message was 'Error in line 1 position 491. Element 'http://tempuri.org/:GetInterfaceResult' contains data from a type that maps to the name 'http://schemas.datacontract.org/2004/07/ServiceSide:WorkInterfaceImpl'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver or add the type corresponding to 'WorkInterfaceImpl' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.

  The InnerException mentioned is a SerializationException with the message:

  Error in line 1 position 491. Element 'http://tempuri.org/:GetInterfaceResult' contains data from a type that maps to the name 'http://schemas.datacontract.org/2004/07/ServiceSide:WorkInterfaceImpl'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver or add the type corresponding to 'WorkInterfaceImpl' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer.

  Notice how this seems to indicate that the system is trying to serialize the type. It is not supposed to do that. It is supposed to generate a transparent proxy instead. How do I tell it to stop trying to serialize it?

• I tried adding an attribute, [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)], to the WorkInterfaceImpl class. No effect.

• I tried changing the attribute [ServiceContract] on the IWorkInterface interface (declared in the shared library ServiceWorkLibrary) to [ServiceContract(SessionMode = SessionMode.Required)]. Also no effect.

• I also tried adding the following magic system.diagnostics element to the Web.config in ServerSide:

    <system.diagnostics>
      <!-- This logging is great when WCF does not work. -->
      <sources>
        <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
          <listeners>
            <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\traces.svclog"  />
          </listeners>
        </source>
      </sources>
    </system.diagnostics>
  

  This does generate the c:\traces.svclog file as promised, but I’m not sure I can make any sense of its contents. I’ve posted the generated file to pastebin here. You can view this information in a more friendly UI by using svctraceviewer.exe. I did that, but frankly, all that stuff doesn’t tell me anything...

What am I doing wrong?

Answer 1

The use-case I am describing is not directly supported by WCF.

The accepted work-around is to return an instance of EndpointAddress10 which points to the service for the “other” interface. The client must then manually create a Channel to access the remote object. WCF doesn’t properly encapsulate this process.

An example that demonstrates this is linked to from the MSDN article “From .NET Remoting to the Windows Communication Foundation (WCF)” (find the text that says “Click here to download the code sample for this article”). This example code demonstrates both .NET Remoting as well as WCF. It defines an interface that looks like this:

[ServiceContract]
public interface IRemoteFactory
{
    IMySessionBoundObject GetInstance();
    [OperationContract]
    EndpointAddress10 GetInstanceAddress();
}

Notice that the interface-returning method is not part of the contract, only the one that returns an EndpointAddress10 is marked with [OperationContract]. The example calls the first method via Remoting, where it correctly creates a remote proxy as one would expect — but when using WCF it resorts to the second method and then instantiates a separate ChannelFactory with the new endpoint address to access the new object.

Answer 2

What you are trying to do is a direct violation of the SOA Tenet: "Services share schema and contract, not class". What this means it that you don't actually pass implementation code from the service to its consumers, just the return values that are specified in the contract itself.

The main focus of WCF and SOA in general is interoperability, meaning services should be accessible to clients of any platform. How would a Java or C++ consumer be able to use this service you are designing? Short answer is that it couldn't, which is why you will find it difficult if not impossible to serialize this code over messaging standards like SOAP.

A more appropriate way to structure this code would be to host each implementation of IWorkerInterface as its own service (it has been defined as a service contract, after all), and expose each service on a different endpoint. Instead of MainService behaving as remote factory for proxies to an IWorkerInterface, it could act a as an endpoint factory to the different services you have set up. Endpoint metadata could easily be serialized and provided to the client by IMainService. The client could then take that metadata and construct a proxy to the remote implementation, either through some custom IServiceProxy implementation, or even through the objects already provided to you by WCF (such as the ChannelFactory).

Answer 3

What is MainServiceClient()? It is the class marshaling the client messages to the server.

You should take a look at a related SO post on returning interfaces as parameters in WCF. ServiceKnownTypeAttribute may be helpful.

Sessions may also be what you're looking for MarshalByRef as it relates to .NET Remoting behaviors.

Another approach (as mentioned on MSDN Forums) is to return the EndpointAddress of the service interface instead of the interface itself.

WCF does serialize everything - regardless of the binding. The best approach you should take if you need to communicate with the service on the same system is to use IPC transport binding (net.pipe).