Question

I would appreciate some guidance on modelling services and operations in WCF.

I have a series of business domains, each with bespoke methods that I want to able to use over WCF. I guess an OO view would be something like:

interface IBusinessDomain1 {     MyClass1 Method1(...)     MyClass2 Method2(...) }  interface IBusinessDomain2 {     MyClass3 Method3(...)     MyClass4 Method4(...) } 

My natural inclination was to make each interface a service and each method an operation, the problem I have with this is that operations within individual domains might well need quite different binding configurations. i.e. Method1 might need to be synchronous, Method2 might need to be asynchronous.

When definining services and operations for WCF, would a better approach be to think in terms of the data types and the way data needs to be sent? Perhaps group methods from all business domains that will need to work in a particular way and have those in one service? I wonder how other people have tackled similar scenarios?

Most WCF tutorials and examples I have seen tend to use fairly trivial models, often a ‘calculator’ service offering ‘add’, ‘subtract’ etc. operations which all share the same binding.

Some advice on how to approach defining my services and operations would be most appreciated, or just some links to further reading as I cannot find much.

Thanks in advance, Will

Answer 1

I think that grouping your contracts together in regards to whether or not they are called in an asynchronous manner is a bad idea. You should still retain the logical groupings for your contracts that make sense.

You also need to elaborate on what different binding configurations you might apply to your contracts. If you need to call a method on a contract asynchronously on the client, then that’s not something the service has to concern itself with, as the client can choose to generate a contract which supports asynchronous operations (where you will get the Begin* and End* methods on the contract which the channel factory will generate for you).

However, if you are doing something like having the service return a token which the client passes back to the service to check on status, you might want to consider a callback interface, as it will make your design much cleaner.

If the different binding configurations have to do with changes in the endpoint (i.e. the transport channel, for example) then you might consider different contracts for different endpoints, but I don’t get the impression that is what you are looking for here.