At work at the moment I’m trying to calculate the migration complexity of our software from .net framework 1.1 to 3.0, with main focus on WCF. Specifically I’ve been doing some test migration of web services to WCF and regenerating our DTO’s to support data contracts. During this test migration an interesting issue came up. With our “old” web services we did our own serialization of DTO’s. Several reasons for that, which I’m not going into now, but this was a bit problematic in WCF at first. I’ll show you a quick example of a typical web service at my company:
[WebMethod]
public XmlNode GetSomeData() {
return StaticBusiness.GetSomeData().Serialize2XmlNode();
}
In the example I just do a call to a static business method called GetSomeData. The return value from this method (which is one of our DTO’s) is then serialized to an XmlNode by calling Serialize2XmlNode().
In WCF we do not want to handle serialization by our self, so we want WCF to take care of this for us and choose the best serialization mechanism available. So our service in WCF would look something like this:
[ServiceContract()]
public interface IMyService {
[OperationContract]
SomeDataObject GetSomeData();
}
public SomeDataObject GetSomeData() {
return StaticBusiness.GetSomeData();
}
One of the reasons why we did our own serialization in 1.1 was lack of xml serialization support for circular references, but in WCF this is no longer an issue.
So as long as my
SomeDataObject has a data contract it will be serialized and returned to the caller. As you probably have guessed we also de-serialized our DTO’s on the client side (since we returned an XmlNode), but that is now of course handled by WCF. Since we did our own serialization we were not dependent on proxy generation of our DTO’s and we could just reuse the dll on the client side. In our case we had .net on both sides so this was ok. In 1.1 we did it like this:
return SomeDataObject.DeSerialize(MyWebService.GetSomeData());
So I was trying to find a simple way of doing this in WCF. The solution was much simpler than I’d ever expected. By manually generating the proxy and using the /r parameter I was able to bypass proxy serialization of DTO’s. Fantastic!
So a typical call to svcutil would look like this:
svcutil /nologo /out:Proxy.cs /r:C:\Test\DTOs.dll /config:App.config /namespace:*,MyProxies net.tcp://localhost:9000/MyService/tcpmex
This gives me a proxy called Proxy.cs and with my method looking like this:
public DTOs.SomeDataObject GetSomeData
{
return base.Channel.GetSomeData();
}
This solved a great challenge for us. My next task at hand is to do some performance testing and see if we get the desired performance improvements by using NetTcp as appose to POWS (Plain Old Web Service).
Thanks to
Rick Strahl for his
great blogpost on this subject.