Building Extensible WCF Service Interfaces With DataContractResolver

I am currently working on a personal project which is purely for learning that involves many categories of skills. I have spent a long time programming on mobile devices so I decided it’s time to attack my weaknesses in my spare time.

I’ve decided to work on an implementation of the Scheduler-Agent-Supervisor pattern blogged about on Clemens Vaster’s (@clemensv) blog that you can find here.

During the initial work I am working on the Queue API’s for sending Job requests into the Scheduler via WCF and an MSMQ binding. I first started off in my first revision with a class called Job which contained a collection of IScheduledTask. I went with IScheduledTask because this way people using the library could implement their own custom versions of IScheduledTask and extend.

The great thing about this approach is the WCF service in theory can receive any task that derives from IScheduledTask. In reality though if the implementation of IScheduledTask exists outside of the assembly of this library WCF doesn’t know how to serialize/deserialize the messages because we are passing in a custom object structure.

In WCF there is a feature called Known Types. This is declarative and not as dynamic as we may want. In the .NET Framework v4 there was a new class addition called DataContractResolver which exposes the hooks we need to solve this problem more dynamically and seamlessly. Alternative we could implement a generic service, which poses a different set of problems I will cover in a future blog post. I felt this knowledge was worth getting out there as there is always more than 1 way to solve a problem.

First let’s replicate the problem before we try to solve it.

Create 2 projects, one called ServiceLib and another called ServiceClient. Add a reference to ServiceLib in the ServiceClient project. Inside ServiceLib let’s add some types.

Read more: kellabyte

Posted via email from .NET Info