Problem in consuming WCF service (basicHttpBinding) in Delphi Win32 Client

Question

I am trying to make a Delphi client (Delphi 2006) to communicate with a service written using WCF. Service is damn simple with just one function. Technically like below:

[ServiceContract (Namespace = "http://www.company.com/sample/")]
public interface IService
{
    [OperationContract]
    string GetNumber (string name);
}

I have hosted this service on IIS and exposed it using basicHttpBinding with mex end point. I am able to use it in .NET clients.

I tried to run WSDLImp.exe and it generated a source code unit (btw, it generates wierd classes to encapsulate string type. Why cant it be same as Delphi string type?). When I try to call this service, I get the exception:

The message with Action '' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

I don't see any way to configure the Delphi Win32 client to changing the binding or security parameters. How can I fix this problem?

Darin Dimitrov · Accepted Answer · 2009-07-07T07:13:18.907

3

I've had the exact same problem. Delphi just has hard time importing the WSDL exposed by WCF. One solution is to add an ASMX wrapper to your service and use that with Delphi clients.

Here's an example:

[ServiceContract (Namespace = "http://www.company.com/sample/")]
public interface IService
{
    [OperationContract]
    string GetNumber (string name);
}

public class Service : IService
{
    public string GetNumber (string name)
    {
        return Repository.GetNumber(name);
    }
}

[WebService(
    Namespace = "http://www.company.com/sample/",
    Name = "wstest",
    Description = "description")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class AsmxService : WebService
{
    [WebMethod]
    public string GetNumber(string name)
    {
        return Repository.GetNumber(name);
    }
}

edited Jul 07 '09 at 07:13

answered Jul 07 '09 at 06:06

Darin Dimitrov

1,023,142
271
3,287
2,928

Sorry but I don't understand what exactly you mean by "add an ASMX wrapper". Please can you elaborate? – Hemant Jul 07 '09 at 06:52
By "add an ASMX wrapper" I mean that you could add an ASMX web service to your solution that has the same methods as your WCF service and these methods perform the exact same tasks. Once you add this asmx web service you get an .asmx endpoint which could be used by Delphi clients. – Darin Dimitrov Jul 07 '09 at 07:15
I wouldn't jump to ASMX anymore: http://johnwsaundersiii.spaces.live.com/blog/cns!600A2BE4A82EA0A6!860.entry. – John Saunders Jul 09 '09 at 00:55
3

@John, I wouldn't jump into Delphi neither. But as you can see there are still people using it (including me) and we have to find solutions to integrate it with newer technology (WCF). I proposed ASMX because it is something I've tested myself and proved working quite nice in production. – Darin Dimitrov Jul 09 '09 at 05:11
I tried what darin suggested and indeed, Delphi seems to integrate with asmx service pretty nicely. It has been pretty smooth. – Hemant Jul 10 '09 at 07:30
WCF Services are created to be consumed and not every consumer is a hostage of Microsoft (yet). Backward compatibility is essential. "standards compliancy" is the bare minimum expected from a reputable organisation. – Sam Mar 09 '11 at 06:06
@Sam: i think it's much more likely that this is a Delphi problem than a WCF problem. I'd love to know what specific difference causes problems for Delphi, though. – John Saunders Mar 09 '11 at 16:56
@John, the whole point of SOAP is interoperability, that's why we use HTTP and XML. Interoperability means catering for existing technologies not just your own. MS could play fair, but it doesn't have to, and it isn't... that's annoying for me. Standards should be phased in with an overlap period, and this should be enforcible by law. – Sam Mar 10 '11 at 01:39
@John, The lack of legal oversight in the technology sector, coupled with the rapid pace of change, is effectively holding millions of IT workers and companies to ransom. "Switch to Microsoft version x or you will lose your livelihood".. that should be an illegal circumstance that people are protected from. It's called "undue influence". – Sam Mar 10 '11 at 01:39
@John, that's an opinion too. – Sam Mar 10 '11 at 01:40
@Sam: what in the world makes you think that WCF is not interoperable? – John Saunders Mar 10 '11 at 02:23
@John, It's not readily interoperable with older SOAP toolkits. It's taken me 3 days(+) to get a flat wsdl... and if it wasn't for the "community" I'd be up the preverbial creek! Admittedly I'm a beginner, but I can't accept the blame for something so rudamentary taking so long. .NET is supposed to make my life easier. All our project estimates and development direction is based on this assumption, which has proven to be misleading. When the project suffers because of this, my livelihood comes under threat and I blame Microsoft for not providing a version of svcutil.exe that does it. – Sam Mar 10 '11 at 02:54
@John, Microsoft has gone out of its way to intentionally make it more difficult to interface with other technologies. It's an old story but it has real consequences for real people. I know the "experts" won't lose sleep over it. – Sam Mar 10 '11 at 02:57
@Sam: WCF isn't the only toolkit that doesn't use a flat WSDL. Under some circumstances, ASMX doesn't, either. Again, this seems more like a problem with the "older toolkit" not accepting the complete WSDL standard (which _does_ permit one WSDL to include another, for reuse), and not the fault of WCF, for actually _implementing_ the standard. To the extent that ASMX uses a flat WSDL, that's more a matter of a lack of features in ASMX as opposed to some lack of standards adherence from WCF. – John Saunders Mar 10 '11 at 03:07
@John, VS2010 should be able to export a flat wsdl with a couple of clicks. ScvUtil should be able to do it with the flick of a switch. Standards compliance is the bare minimum expected from a reputable organisation that's holding the whole market to ransom. Standards should be phased in with an overlap period... yadda yadda yadda – Sam Mar 10 '11 at 03:20
@Sam: I'm sure Microsoft will thank you for your help in designing their next release of Visual Studio. Please share this with them at http://connect.microsoft.com/visualstudio/. – John Saunders Mar 10 '11 at 03:22
@Sam: the WSDL standard has always permitted included WSDLs, and the XML schema standard has always permitted included XSD. You're really barking up the wrong tree here. You should complain to the vendor of the tool that can only handle flat WSDL. – John Saunders Mar 10 '11 at 03:23
@John, Easy, I'll tell them to uncomment the code that makes it work for everyone (not just those with other MS technologies). WCF already handles both, but one is intentionally much more difficult to arrive at. You're also failing to grasp the human cost of rapid technological change. – Sam Mar 10 '11 at 03:53

score 2 · Answer 2 · answered Jul 09 '09 at 00:54

2

You need to look at the network traffic between the client and service to see what's going on. Alternatively, turn on WCF tracing on the service, possibly including message tracing. You should be able to see what's going on, in great detail.

answered Jul 09 '09 at 00:54

John Saunders

160,644
26
247
397

This is an answer and an opinion! +1 – Sam Mar 09 '11 at 06:12

Problem in consuming WCF service (basicHttpBinding) in Delphi Win32 Client

2 Answers2

Linked