Introduction

In this post, I will try to explain the motives behind using routing services as transport bridging with a sample solution. With references to WCF 4.0,  other stuff, this will be interesting journey.

Before going into details, let’s explain fundamentals:

What is a routing service?

A routing service that comes with FW4.0 (WCF 4.0) is just like another WCF service, except this service is sealed, so it can’t be inherited, as shown in the image below:

Routing Services can be used for different purposes; content-based routing, WCF services with fail-over feature,  SOAP processing, error handing, as well as transport bridging.

What is protocol bridging?

In my prior post, I have done a POC study on having a WCF service with multiple endpoints having different protocols. Yes, it is a solution, however, it was not my favorite. With this post, I will create a better solution.

WCF supports the following transports/protocols:

As you see, the only protocol interoperable is HTTP/HTTPS. Therefore, generally speaking, external services (services that are consumed by external clients which you don’t have control over) use HTTP/HTTPS protocol, whereas internal services may use other type of protocols due to performance & security reasons. A routing service can bridge this 2 ends –protocol bridging. To make it clear, let’s draw a picture:

Here, the router service bridges TCP/IP to HTTP protocol or vice  versa. You may see the benefit here, you can encapsulate your internal services from outside (by DMZ, implementation boundary, etc.).

Show me a working sample

I am going to start with a simple service then add complexity as much as I can. The solution will include 3 different projects a service library representing internal services, a service application representing router services, and a test project testing the solution –yes, it is not a typical client.

1. Create a service library project

Firstly, let’s create a Service Library project named ‘ServiceLibrary’ within a solution called ‘Routing’ by using WCF Service Library project template via VS 2010. After doing some clean up by removing comment lines and complex type object method from the service, and replacing base address with absolute URL for service and mex addresses, the picture should be like this:

2. Create a test project

Name it ‘ServiceApplicationTest’, then add service reference as shown in the picture below:

Please remember we are not referencing the library project but the service in that project. Then, add a new unit test class called ‘IService1Test.cs’  (Right click on ServiceApplicationTest project –> Add /New Item –> UnitTest).

After doing some clean-up again, my test method would be like this.     
  

Set the test project as start-up project and then hit F5, and it works as expected.

Here some basic stuff need to be cleared:

1. ServiceLibrary project is hosted in WCF Service Host (WCFSvcHost.exe)
2. Projects references to only required assemblies, no need for serialization (string used only) and data access
3. WCF 4.0 provides default values for binding and behavior configurations if nothing specified explicitly, that is why you don’t see anything special on ServiceApplicationTest project’s app.config file.

3. Create a service application project

Ok, our service at the destination and test project works fine. Now, it is time for developing routing service that will bridge HTTP to TCP protocols. To do that, simply add a new WCF Service Application project to the solution. From here, all we need to do is modify web.config file accordingly. Here are things to do here:

1. Add your filter and filter tables under <routing> section
2. Add <client> section that has address attribute pointing to the target service “net.tcp://localhost:8732/ServiceLibrary/Service1”
3. Add a service named ‘System.ServiceModel.Routing.RoutingService’ with a behavior having reference to the filter  table that is going to defined below. ABC would be:
1. Address: ”RouterService”
2. Binding: wsHttpBinding
3. Contract:‘System.ServiceModel.Routing.IRequestReplyRouter’ (There are other type of contracts supported by the model depending on the pattern your message will follow)
   
4. Add service behavior section where routing table specified.

At the end, web.config file should be like this:

After adding a .svc file, as a last thing, let’s assign a specific port to service application

Routing service is ready now, you can test by running it.

Ok, now time is to switch testing project calling routing service instead of targeted service. So, please update app.config file as below:

When you run the test project, it runs successfully.

Prove it

Mission is completed as in its simplest form. Now, let’s step ahead and see what is really going on behind curtain –pipeline. A message inspector class would help us on this. To make it short, I have created classes for inspection and behavior extension as  seen below in both application and library project (reserving their namespaces):

When run the test with debug (breakpoint in each node in the pipeline, you will see messages flow as :

That is it for now. Working solution attached here for your convenience.

Summary

In this blog, I have created a routing service that bridges from/to HTTP to/from TCP/IP protocols by utilizing WCF 4.0 Routing Service. I have used message inspectors to see inner works in some degree. Solution can be extended for different purposes (performance analysis, unit testing, custom messages, etc.). Hope you find it beneficial.

References

• WCF 4.0, New Features http://msdn.microsoft.com/en-us/gg465212
• Routing Service, msdn, http://msdn.microsoft.com/en-us/library/ee517423.aspx
• Message Inspectors, msdn http://msdn.microsoft.com/en-us/library/aa717047.aspx