Kristian Kristensen’s Blog

WCF brings many good stuff to service development. A lot of thought and care has been put into the stack to ensure that it is flexible and future proof. Given that it is new and involves a lot of rethinking it also implies that it might do things differently than previous stacks.

One such change is in the generation of the WSDL from a service. Assuming that we have a service bound to the endpoint http://localhost/MyService we could obtain the WSDL for this service by hitting http://localhost/MyService?wsdl. By default his WSDL will be split up into separate files containing the necessary information to describe the services operations and input/output. This is pretty neat since it makes it more human readable than one big file containing everything. So far so good.
Another web service implementation from Microsoft is ASP.NET Web Services or ASMX. It uses/used the latter method of WSDL publication: one big file. So did other stacks. Recently I had to make a client built using Delphi 7 use a service from WCF. The built in web service stack in Delphi prefers/requires that the WSDL is contained in one file. If it is not it cannot generate a proxy class, and cannot communicate with the service. There is a discussion of the issue by one of the Delphi 7 developers here. He recommends either flattening the WSDL (ie. include all the WCF generated files in one big file), or use RPC encoded services.. The latter option isn’t really an option in my current context, so I looked at how to flatten the WSDL. Of course I’m not the only one with this request, so a quick Google search reveals a number of solutions:

• There’s Christian Weyer’s post on Flattening your WSDL
• Tomas Restrepo on Inline XSD in WSDL with WCF

Using Weyer’s FlatWSDL class I was able to generate a Delphi proxy class. However, I still couldn’t call my methods. The reason was that my contract is specified in an interface.
Tomas Restrepo writes:

This will not get rid, however, of any wsdl that WCF might be generating, such as the case when the service implementation and the service contract interface are in different namespaces.

My problem exactly. So if I remove my interface based services, and use plain classes, I can call my service operations. So far so good. But I still have one problem, the Delphi generated SOAP request is somehow not recognized by WCF. The correct operation gets called, but the parameters are not transferred correctly.

So where do I stand? I’ve flattened my WSDL for backwards compatibility. But my Delphi (dare I say legacy) client still cannot call my operation. I think that my next step is to convert my service into a POX service, and expose it via some kind of plain RPC. It doesn’t get any simpler than that, and this method should be supported by any type of client. If all else fails you can handcraft the request XML yourself and POST it to the service.