Marriage of WCF and ASMX

I never imagined that writing a simple POX based application with correct interface semantics in the current release of WCF would be such a pain. Wait. It is impossible.

The intent was to expose a WCF service that can return POX when invoked through a regular well-formed URL with Query strings or submit HTML form data to it while doing a HTTP-POST -- Just like we used to do in the good ol' ASMX days. Guess what, this feature is not natively built into the current release of WCF.

Well, the WCF geek would be shrugging his head right now, itching to show me the way to build WCF services that can be consumed by HTTP-GET/POST verbs and can return POX. Not so fast, boy. I'm cognizant that one can build services which can return POX but they are loosely typed i.e. they have to declare methods which can only take Message type as an input. What does one do when one has to define operation contracts that need to define native data types as input parameters in the method signature?

Okay, I lied.

I know there is yet a better way -- To build a router, basically a message inspector, that can route the messages to the right operation contracts by inspecting the kind of action that is desired by the user. But, can you imagine how much code one would have to write to build this router in the context of a gigantic enterprise class application? I think you already know the answer. At least, I don't want to. As a matter of fact, I cringe imagining someone writing that kind of code as it would not be maintainable in the long run.

The good news is that WCF in .NET 3.5 would support the desired feature set out of the box but the bad news is that the upcoming framework is still in beta and to make matters worst, there isn't any confirmed release date. We have to roll out the system in production by January thus couldn't bet on the beta release. Thus, I ended up choosing ASMX to build our service delivery platform. But, I really wanted to harness the power of WCF to build the service delivery platform as it provides options galore to configure and host services.

So, what did I end up doing? Married both the technologies. Our service interfaces have both the WebService and ServiceContract Attributes, the methods have both the WebMethod and OperationContract Attributes. We ended up created ASP.NET Web Services project and decorated the WCF tags on the services which would allow us to switch to the new framework when it comes out without compiling the code. Of course, we would have to provide the right configuration to host it as a WCF service but still we wouldn't have to touch the code. Here is how a service interface looks like --

This way we de-risk ourselves by not adopting a beta product but still be ready to embrace the new framework. Have you grappled with this problem and have a better solution? I would appreciate if you can take the time out to share your thought process.