WCF contract returning interface could cause serialization issue?

Question

I am trying to define a WCF contract that returns an interface, something like below:

[ServiceContract]
public interface IMyContracts
{
    [OperationContract]
    IMyInterface GetData(string request);
}

To get this to work I think my interface (IMyInterface) would have to implement ISerializable to ensure classes implementing my interface can be serialized. This then means I have to manually implement serialization for any classes implementing my interface.

It seems that either I use my interface and risk runtime errors if a class is used that is not serializable, or I make the interface implement ISerializable and have the associated hassle of manual implementation.

Am I confusing myself and missing something obvious? How have other people returned interfaces using WCF and avoided this problem?

Thanks very much.

Solution

AFAIK, the problem is not with serialization but with the fact that you're returning abstract entity (an interface). Abstraction is an OO concept, not SOA concept. So, your client's wcf stack may not know what to do with the class behind the interface. What if the client does not know the class behind the interface. Client's WCF stack must deserialize it, and to do it, it must know the class.

So, you must make the class(es) behind the interface part of your contract, via KnownTypeAttribute.

You may also use ServiceKnownTypeAttribute class that seems to be more flexible. Still, remember that the client must know the type, or you'll get an exception.

Comments

[Nicolas Dorier]

Take a look at Exchange Web Service : msdn.microsoft.com/en-us/library/bb204119.aspx, it uses polymorphism heavily. This is not a simple web service to use but it is very powerfull and coarse grained.

[ssss]

It is not true that “the client’s WCF stack must deserialize it”, and nor need it know the class. It is supposed to use a transparent proxy and channel all the interface method calls to the server which has the instance. The whole point of interfaces is so that you can provide functionality to a client that doesn’t know your concrete type. (In other words, your answer doesn’t help.)

[Krzysztof Kozmic]

@Timwi, with all due respect, I think you misunderstood the question, or how WCF works. Rather than just claiming It is not true please provide a reference to a source that backs your claim.

[ssss]

It is true that I don’t know WCF very well. I know .NET Remoting though, and I don’t think I have to back the claim that .NET natively supports transparent proxy objects for interface types because anyone who’s ever used .NET Remoting has seen them. If WCF requires the client to deserialize a class, then it blatantly fails to accommodate the most obvious use-case, which is to access an object on a remote server (which may or may not be serializable).

[ssss]

If that is indeed the case, then “you can’t do it with WCF because WCF doesn’t support it” would be a more helpful (and more honest) answer than one that makes false claims such as “the client’s WCF stack must deserialize something”, or one that encourages programmers to break implementation encapsulation and/or design gaping security holes into their applications (which “you must make the class(es) part of your contract” does).

[Erik Decker]

@Timwi, I think in this case WillH is using WCF for Web Service invocation and not Remote Method/Object Invocation (aka Remoting) where the object has a multi-call lifetime on the server.