Basic Request Response WCF service

The concept of Request-Response service is to have an endpoint with a single function capable to handle a command (a Request) and return a Response, to have a single entry point of our service. There are a lot of architectures around the web based on WCF and this pattern and this old series of post are a really good example on how you can implement it in practice.

The only drawback is that sometimes these architectures are quite complex for the average programmer, at least you can introduce them in a team where everyone is quite familiar with concept of Inversion Of Control, Dependency Injection, etc etc. The risk is that people are scared about the complexity and they start to believe that the benefit of such an architecture does not worth the extra complexity of the code, after all with WCF you can simply create a function on the interface, an implementation on a service class, update service reference and the game is done. On the contrary, some implementations of Request/Response pattern are quite complicated, you need to create a request, then the handler, then configure the IoC engine, etc etc.

Another problem is that one of the key requirement of an architecture is that it is perfectly understood by the whole team, if some members use an architecture without fully comprehension, you are in trouble because you are creating a bottleneck because only some person of the team are capable to modify base architecture or solve bugs. This can lead to a fight between programmer and architecture, because everytime the service does not behave correctly people are puzzled on what happened (maybe the IoC engine is badly configured, maybe some interceptor created error, etc etc)

So I got a request from a team, how much is the minimum code that I need to create a Super Simple Request/Response architecture in WCF, the purpose is verify if it is simple enough to introduce in team unfamiliar with IoC, DI, and with a very basic skill of WCF. This approach is preferable, you can show how simple is to implement such a pattern with a minimum set of functionality, then when the needs of the team start to grow, you can evolve the architecture one step at a time, making it really comprehensible by the whole team because they fully understand the reason of each piece of the game.

The starting point is creating an interface, a concrete implementation and finally two base classes called Request and Response.

image

Figure 1: Base classes to create a super simple Request/Response sample

As you can see I have a simple ICoreService interface with only a method called Execute, that accepts a Request and return a response. The CoreService concrete class implements the IDisposable interface (more to come) and the execute method. Then I have a basic Request abstract class with an abstract method called Execute(), finally the base Response class has only two property: IsSuccess to inform if the operation completed successfully, and an ErrorCode, to contain an integer code of the error (but you can include more common property if your client needs to know you want in your basic Response class). Here is the code for the base Request class.

image

The class is really simple, just add the DataContract attribute and the abstract method. Here is the code for the CoreService class. The core concept is that it simply add some infrastructural code (the try catch at the minimum level) and it simply call Execute method that will be implemented by the real request class.

image

This class implements IDisposable because the ICoreService inherit from IDisposable (I show the reason of this structure in a future post), but the core part is that it simply calls the Execute abstract method of base Response class in a try catch. Now lets see how we can implement an operation to add Two numbers.

image

As you can see this is really simple, create one class, insert a property for each input parameter and override the Execute method. With such a simple architecture everyone can use it without any fear of “not understanding the big picture”. The only other class you need to create is the MathOperationResult that inherits from Response and add an OperationResult property to return the result of the operation to the caller.

The only other infrastructural class needed to make this code works, is a class that instruct the WCF engine at run-time on all the types that can be used in the contract, called KnownTypes. The ICoreService interface is decorated with a ServiceKnownType attribute that specify the class that is capable to give the list of known types at runtime.

image

Implementing such a class is really trivial.

image

In static constructor I scan the current assembly to find all non abstract types that inherits from Request and response and store them in a list, that I return in the GetKnownTypes. This technique is really useful, because you can also scan for all assembly in a directory, so you can load at runtime Requests originally unknown from the original service as a plugin. Thanks to this great flexibility of WCF, you can use WCF infrastructure to handle all serialization issue for you.

The client can simply add a service reference and call the service with this code.

image

Figure 2: You can add a normal service reference from another project

Here is the call.

image

The only drawback of this architecture is a little verbosity in client code, that instead of calling something like Add(12, 32), needs to create the request, cast the response to the right type and verify the success of the operation, but you have the advantage of a single entry point of your service, where you can put all the common logic you want and every person in the team can fully understand what is going on.

Gian Maria.

Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

10 thoughts on “Basic Request Response WCF service”

  1. Hi Alk,

    there is something I don’t like on this approach, which is the casting you have to perform on the result object. Moreover, what if my request is more than just summing up to numbers (e.g. business services invocation, ecc ecc…)?

    Thanks,
    petrux

  2. Sorry for the late response. The cast needed by the caller is not really beautiful, but if you have a single entry point capable of handling command, the caller should know for each command the type of response.

    For business service I do not see any problem, you just send a request that can be “create order”, “cancel order” and so on, without any problem.

  3. Great post, I’ve found it extremely useful. One question though:

    How would you proceed if you wanted to eliminate the Execute method on Requests? That’s the only part I’m not comfortable with. Doesn’t seem to be the responsibility of a request object to know how to generate a response. I’ve always thought about requests and responses as messages and it feels weird for them to have behavior.

    I was thinking of having a switch statement that delegates to the appropriate class depending on the type of the request but I’m wondering if that’s an antipattern.

  4. @Ariel: yes, the Execute on Request object is the main pain point of this solution, but it is acceptable because the aim was to have the simpliest thing that could possibly work.

    This is only the first post of a series, I’ve already code and a couple of blog post (I need to finish to write and review them) of a logic evolution where the execute method is moved to handlers dynamically loaded with MEF :).

  5. I’ve blogged right now the second version of the Request Reponse Service that uses MEF to dynamically loads handlers, it is scheduled to be online on monday morning.

  6. Pingback: Team Work

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.