Problem with SoapHttpClientProtocol Invoke()

[cGemm11]

Hello. I am having a problem with the SoapHttpClientProtocol recognizing a class hierarchy defined in my WSDL and schema. I am using VC#2008Express to import a WSDL from my SOAP server and build a basic client app. I have a base class A and a subclass B extending A. The WSDL defines an action that can be invoked that returns an instance of A. When queried, the server responds with an instance of the subclass B. However, the VC# client returns null, instead of the returned instance. I verified the server is returning the correct object with Wireshark, and with another soap package (soapUI reads it correctly). Can anyone suggest something that may be wrong here?

BTW, I saw an older post (12/2005) that seems to be related, where the solution seemed to be that the schema was defined without the elementFormDefault="qualified" attribute. Adding that fixed the problem for the poster. In my case, my schema does in fact have this attribute already.

Any help is greatly appreciated!

[Plater]

So you have one side that returns an instance of B(which inherits from A).
And the other side expects an instance of A.
And they are not playing nice?
Is there any sort of type-casting that can be done?
I am on the whole unfamiliar with webservices and soap calls. Perhaps there is some sort of security setting or option field that tells it to no be so picky about what object type is returned to it?

[cGemm11]

Thanks for reply! Please let me know if I'm missing something obvious here.

Yes, that seems to be the situation. My server exposes its WSDL and schema, and I am using VC# to build a SOAP client to make a simple query to my server. When the VC# SOAP client gets an instance of B (which is also an instance of A by inheritance), it does not recognize that it got an instance of A and simply returns null. Unfortunately, I do not believe the server could typecast, because it is putting an XML fragment into the SOAP envelope, and it is not feasible to throw away the type information just to package it up as an instance of A. I am also not very familiar with the world of SOAP and web services, but would be happy to see exactly what you suggest, some sort of flag that would indicate not to require an instance only of A, but also to allow subclasses of A. Coming from the Java world, I would have expected this to happen automatically!

[Plater]

If you are building the client side, why not have it expect an instance of B instead of A?

[cGemm11]

Good question. Actually, we have provided the server side, and I have customers that are trying to build their own client side apps to interface with the server side. My client side app is just a simple proof of concept, read and print app. But to answer your question in general, the reason is that a client app would not necessarily know that the reply would be of type B. It is simply saying get this object, which I know is of type A. In fact, there are many different subclasses of A, not just the one. So it isn't possible to know ahead of time exactly what type to expect. You can see where something that should be a simple test has gotten far more complicated than it should have. :-)