WCF and Interface Inheritance - Is this a terrible thing to do?

Question

My application has 2 "services", let's say one is a basic (integer) calculator, and one is a floating point calculator. I express these as interfaces like so:

public interface IBasicCalculator
{
 int Add( int a, int b );
}

public interface IFloatingPointCalculator
{
 double Add( double a, double b );
}

I want to expose these via WCF. Unfortunately WCF seems to be very tightly tied to the notion that every possible operation you want to expose must go through one single service interface -- you can't share sessions between services, it is cumbersome from the client side as you need to create a seperate proxy for each one, there don't seem to be any "sub-services", etc...

So, I've gathered that I need to present a "combined" interface (one might also call it a facade), like this:

[ServiceContract]
public interface ICalculatorService : IBasicCalculator, IFloatingPointCalculator
{
 [OperationContract(Name = "AddInt")]
 new int Add( int a, int b );

 [OperationContract(Name = "AddDouble")]
 new double Add( double a, double b );
}

If I do this, then WCF exposes both methods to the client, which can call them, and it all actually works.

However, "inheriting the interfaces" like that seems to be ungainly. Particularly the new int Add and new double Add. Strictly speaking, new on a method indicates hiding an underlying method, which I'm not actually doing at all. I can omit the new, but then I just get compiler warnings which amount to "I think I'm hiding this method, you need to rename it method or put 'new' on it".

So, this is a 2-part question:

1. Am I on track with my 'combine everything into one interface' logic, or is there actually a way to expose "sub-services" or "multiple linked services" using WCF?

2. If this is what needs to be done, is there a better way?

Thanks!

Answer 1

I would say generally, no. Remember, you are dealing with a distributed application technology, not a distributed object technology, so concepts like inheritance don't apply.

In general, I wouldn't go down this path, but rather, have specific contracts which represent the logical grouping of operations that you want to expose through the endpoint.

Answer 2

I just worked out that you can expose multiple endpoints (each using a different interface) to the same service, and you still only need generate ONE proxy lib on the client which gives access to all of them, which solves my problem entirely.

Will close the question as it's no longer relevant (need 2 more votes from other users to do so). Cheers

Answer 3

I believe that what you are describing is not really a best practice though. Sure, it is feasible to implement more than one Service contract on a Service type, since it is just a matter of implementing multiple interfaces.

WCF certainly makes it feasible to support multiple endpoints that communicate using unique URIs and independent contracts. However, the fact that the ClientBase class only accepts one contract interface type, for example, pretty much implies that proxy classes, even if they are stored in the same lib, still need distinctly implement only one contract interface.

If you are actually successful in creating only one proxy class definition, I would love to know how you managed to accomplish this. I may be misunderstanding your needs though. Implementing different proxy classes gives you the ultimate flexibility because the OperationContractAtrribute values like IsInitiating and IsTerminating will likely be different for different contracts. Combining the interfaces of two contracts, as in your example, potentially changes the way you would attribute the methods on the Service contract.