WCF is surely a big step forward for having a unified communication runtime, API and hosting model. And with all these super-exciting specifications and standards supported WCF must be a killer when it comes to interoperability with other platforms, technologies, stacks. And now the communication gurus from Redmond even announced that they will support everything to imagine (OK, except CORBA, ICE and Remoting wire interop ;)) under the big communication umbrella - including popular rockstars like REST-style architectures, RSS- and Atom-driven feeds and JSON for the AJAXians. Oh, and of course they still love SOAP. You know: love is the message and the message is love. So life is good, right?
Well, yeah... in theory.
Back to real life.
I was approached by customers recently. Each of them had to interop with some issues when trying to point there 'other' technologies to a WCF service. And yes, this service was a plain old 'Web Service' - i.e. basicHttpBinding, no security ;), using the default DataContractSerializer with no fancy versioning or even extensibility stuff. Well, something pretty straight-forward at the end of the day.
But these other technologies - namely Flex and PHP - could just not get their code generated (statically or dynamically) from the metadata exposed by the basic and simple WCF service. Hm... it is actually neither's fault, maybe we could blame Microsoft that they are ahead of the rest of the world - maybe we could blame the others that they have no time to invest in improving supporting WSDL and XSD on their platforms. But in the end, nobody is to blame, nobody has to complain: we simply need a solution. Period.
It turned out that both technologies struggled with the way WCF is exposing
the WSDL and XSD metadata by default. IMHO, WCF does a good job in factoring the
XSD and WSDLs into multiple parts and not pumping everything into one big WSDL
document. But the others just do not like it. Take a look at the following WSDL
from our popular
RestaurantService sample, just ported over to WCF (parts removed for
Other platforms just do not like this kind of factoring out the XSDs into external, although virtual, locations. It gets even worse when you do not remember to set all necessary namespace values. Kirill wrote about this some time ago and my friend Beat and I were also struggling with this a along time ago, It is not very obvious in the first place which properties you need to see and especially why. But once you accept it, this is how it goes:
|<binding>||è||bindingNamespace on endpoint|
With a namespace value being present in [ServiceContract], [ServiceBehavior] and bindingNamespace we are good to go and will no longer see that WCF imports a wsdl1 into the root WSDL - essentially, the WSDL shown above results from already setting these values correctly.
OK. Done? Nope.
We still have these xsd:import statements
which so many other aliens are not happy with. We need to get rid of them.
Tomas already talked about the basic idea the other day, but I needed to
tweak it a bit and further enhance it.
We need to hook into the WSDL generation process inside WCF and rip out the XSD imports and place all that stuff straight into the schema section of the WSDL.
The idea is to implement the IWsdlExportExtension interface in a class called FlatWsdl in order to get our fingers onto the metadata. We attach this extension to the WCF runtime by having an endpoint behavior. When hosting a service in your own application you can just add the endpoint behavior to your appropriate endpoint(s) like this:
ServiceHost sh = new ServiceHost(
foreach(ServiceEndpoint endpoint in sh.Description.Endpoints)
When now pointing a browser to the WSDL, we see what we wanted to see (parts
are omitted for brevity):
Yes, that's it.
But still I was not completely happy with my solution. Do I really always need to add this behavior to my endpoints? No, let's look at creating a custom ServiceHost that does the (kind of) heavy-lifting for us.
public class FlatWsdlServiceHost : ServiceHost
public FlatWsdlServiceHost(Type serviceType, params Uri baseAddresses)
public FlatWsdlServiceHost(object singeltonInstance, params Uri baseAddresses)
protected override void ApplyConfiguration()
private void InjectFlatWsdlExtension()
foreach (ServiceEndpoint endpoint in this.Description.Endpoints)
Whew - that was easy. Thanks to
Steve and friends for
making it such easy.
Now my service hosting code boils down to this, which is really sexy:
FlatWsdlServiceHost sh = new FlatWsdlServiceHost(
OK, now we are done!
No. What about web-hosting this service? What if I want to host this service inside of IIS and/or W(P)AS? Gladly, the good guys in Redmond provide us with a way to hook into the web-hosted activation, as well. ServiceHostFactory to the rescue! With a custom factory we can instruct the web host to use this one - and then we are on the safe side to just return our just implemented FlatWsdlServiceHost. The .svc hook then looks like this:
<% @ServiceHost Language=C# Debug="true"
And for the sake of completeness, this is the simple factory:
public sealed class FlatWsdlServiceHostFactory : ServiceHostFactory
public override ServiceHostBase CreateServiceHost(string constructorString, Uri baseAddresses)
return base.CreateServiceHost(constructorString, baseAddresses);
protected override ServiceHost CreateServiceHost(Type serviceType, Uri baseAddresses)
return new FlatWsdlServiceHost(serviceType, baseAddresses);
This means that we can use the FlatWsdl
extension in both. self- and web-hosted scenarios with close-to-zero intrusion
from a programming model perspective. Sweet.
Wonderful - now I am satisfied.
Conclusion: WCF is extremely extensible - and this extensibility has
helped me out already several dozens of times.
But then, WCF also makes the life of the common developer not always easier when caompared to the 'outdated' stacks - in fact, in some very popular situations and scenarios it may be a bit of a pain. You just need to know how to fix it.
Needless to say that my two customers where very happy. They could now easily
point their codegen tools of choice to the WSDL and generate code and
afterwards successfully talk to the WCF service (talking is a totally different
Please feel free to download the complete sample and give some feedback on it. Thanks.
P.S.: In homage to FlatEric (dedel-dede-dedem---dedel-dede-dedem...)
I am calling this extension FlatWsdl.