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:
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.
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.).
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:
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:
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.
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.
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.
Thank you very much for this very clear primer. The pictures help a lot.