Upcasting ServiceContract

Question

Hi,

I have a WCF service, which exposes many methods.

My application consumes this service, and ServiceContract includes OperationContract definitions for only some of methods.

To cut to the question, consider following code example:

[ServiceContract]
public interface IServer
{
    [OperationContract]
    void BasicOperation();
}

[ServiceContract]
public interface IExtendedServer : IServer
{
    [OperationContract]
    void ExtendedOperation();
}

I would like to make contracts so that application has extension capability. In other words, I'd like to be able to use IServer contract everywhere, but to allow plugin-like architecture to extend basic contract interface, so that plugin itself can call ExtendedOperation() operation contract.

So, how do I structure my code, or, what changes do I have to make, in order to be able to do something like following? (channel is of type IServer)

((IExtendedServer)channel).ExtendedOperation()

When I attempt to do this, I get error

System.InvalidCastException : Unable to cast transparent proxy to type 'Contract.IExtendedServer'.

I hope I wasn't confusing...

Answer 1

I'm not sure what you're trying to accomplish here. You're dealing with services, which have endpoints exposing specific contracts (i.e. interfaces). You're not dealing with objects and casting and the like; it won't work and isn't the right approach anyway.

The way I see it, what you have is indeed just that: A service that exposes one endpoint with a set of common operations, and potentially X number of additional endpoints with other contracts with extension operations. You could still have a single service class on the service side, but as far as the client goes, they are simply different endpoint/services.

Answer 2

Services in a SOA world need to have a well-defined and pretty static interface. SOAP services require a representation in a WSDL (and included or separate XSD = XML schema for the data involved).

I don't see how you can create something like a plug-in system in a service world. Plugins work great on a local app - load your resources, language extensions, graphics filters - whatever strikes your fancy. But in a SOA world, this "agility" is the exact contrary of what you're trying to do - create and offer well-defined, fully specified services to be used.

The only option I could see is using a REST-based approach, since there you don't really have many of those limitations. Normally I say this lack of a formal service description is one of the major drawbacks and weak points of REST, but since using REST, the operations are really just defined by the URL's used, this might be a plus in your case.

So I would say: if you really want flexibility in services, you need to check out REST based services. SOAP doesn't fit that bill. Go to the WCF REST Developer Center on MSDN for a vast array of information and resources on how to use REST in and with WCF.