Serialising SOAP parameters in C#

Question

I'm trying to write a .Net client to a vendor's SOAP Service, but I'm having trouble getting the parameters to the SOAP messages to serialise to a form that the service recognises.

Using wsdl.exe I generated a service proxy class which works fine in itself. However, one of the messages takes an argument which is an array of key/value pairs - this is the bit I'm having problems with.

The WSDL for the message is:

The service proxy class has this code:

[System.Web.Services.WebServiceBindingAttribute(Name="EngineSoapBinding", Namespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts/wsdl/")]
internal partial class Service : System.Web.Services.Protocols.SoapHttpClientProtocol {

    ....

    [System.Web.Services.Protocols.SoapRpcMethodAttribute("http://www.smarteam.com/dev/ns/iplatform/embeddedscripts/action/Execute", RequestNamespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts", ResponseNamespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts", Use=SoapBindingUse.Literal)]
    [return: System.Xml.Serialization.SoapElementAttribute("Result")]
    public object Execute(string ContextHandle, string ScriptLanguage, string Script, object Params) {
        object[] results = this.Invoke("Execute", new object[] {
                    ContextHandle,
                    ScriptLanguage,
                    Script,
                    Params});
        return ((object)(results[0]));
    }

    ....

}

In the vendor's documentation the Params argument should be an array of key/value pairs.

I've been able to capture network traffic from another working client to this service and got the following example of a message that the service recognises (SOAP envelope removed and formatted for clarity):


    0019469#00228
    javascript
    
    
        
            Number
            10
        
        
            Hello
            World

I've tried various data structures for the Params argument, but nothing I've tried gives anything close to this XML serialisation.

The closest I've been able to get is to write a DictionaryItem class which implements IXmlSerializable with the following WriteXml method:

    public void WriteXml(XmlWriter writer)
    {
        writer.WriteStartElement("key");
        writer.WriteValue(Key);
        writer.WriteEndElement();
        writer.WriteStartElement("value");
        writer.WriteValue(Value);
        writer.WriteEndElement();
    }

I then give the Params argument a List which results in the following serialization on the wire.


    0022541#00228
    javascript
    
    
        
            Number
            10
        
        
            Hello
            World

Can anyone point me in the right direction to get this working?

** Update **

It doesn't surprise me in the slightest that this vendor is using a deprecated message format. Their whole product is a mess, and I'd gladly ditch it if I could. It's written in .Net, but has a COM API and this web service in a deprecated format. They do supply a client library for the web service, but it's writtn in Java. Huh?

I'm going to go back to my original idea and write a wrapper around the Java client, using ikvmc. At least I know I can get that to work, even if all the type conversion will be messy.

As for picking an answer @Cheeso and @Aaronaught have both been very helpful, so I've flipped a coin and given it to @Cheeso.

Cheeso · Accepted Answer

The example message you've shown there shows a message using what is known as "SOAP Section 5 encoding". SOAP encoding (not to say SOAP) was deprecated by all major tools and services vendors a looooong time ago, due to problems with compatibility and interoperability. Like in 2004 or so.

Seriously. Nobody should be using that stuff any longer. There is no excuse.

But even so, you should be able to get it to work.

The challenge is to get the XML namespaces right on each of the request and response elements. Just looking at the example request message - the one that "works" - you can see it's sort of deranged. There's the namespace with the STES prefix on the toplevel request element - Execute. Then, all the child elements get no namespace at all. This is weird.

The same weird on/off namespace thing occurs in the Params array. The wrapper element is in the namespace with the sof prefix. But the key and value child elements are not in that namespace- they are in no namespace at all.

In your attempt, you have a couple mismatches then;

In your case, the DictionaryItem element is in the http://www.smarteam.com/dev/ns/iplatform/embeddedscripts namespace. It should be in the http://www.smarteam.com/dev/ns/SOF/2.0 namespace.
In your case, the key and value elements are in the http://www.smarteam.com/dev/ns/iplatform/embeddedscripts namespace. They should be in no namespace at all.

Normally a proper WSDL means you do not have to worry about any of these things. I am puzzled as to why your WSDL is not generating a proxy that does the right thing. What I recommend people do in this case is get a wSDL that really works. Oftentimes that means writing a mock version of the service in ASMX.

If you can generate a service in ASMX that accepts messages of the form accepted by the real service, and if you can generate a client that interacts with that ASMX service, then the client should also work with the real service. the reason I recommend ASMX is that it's so easy to tweak and retry things.

Toward that end, here's what I cam eup with.

<%@ WebService Language="c#"
      Class="Cheeso.CooperService"
      %>

using System.Web.Services;
using System.Web.Services.Description;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
using System.Collections;

namespace Cheeso
{
    [SoapType(Namespace="http://www.smarteam.com/dev/ns/SOF/2.0")]
    public class DictionaryItem
    {
        public string key { get; set; }
        public string value { get; set; }
    }


    [System.Web.Services.WebService
     (Name="EngineSoapBinding",
      Namespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts/wsdl/")]
    public class CooperService : System.Web.Services.WebService
    {

        [WebMethod]
        [SoapRpcMethod
         ("http://www.smarteam.com/dev/ns/iplatform/embeddedscripts/action/Execute",
          RequestNamespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts",
          ResponseNamespace="http://www.smarteam.com/dev/ns/iplatform/embeddedscripts",
          Use=SoapBindingUse.Encoded)]
        [return: System.Xml.Serialization.SoapElementAttribute("Result")]
        public object Execute(string ContextHandle,
                              string ScriptLanguage,
                              string Script,
                              DictionaryItem[] Params)
        {
            return "The answer is 42. What is the question?";
        }

    }
}

This ASMX file should produce a WSDL and an interface that is equivalent to your real service. Generate the WSDL from it (using the ?wsdl query), and then write a test client. Examine the messages on the wire and tweak as necessary.

You can see that I applied a REAL type to the Params array. Also I decorated that type with the SoapType attribute and specified the desired xml namespace.

In your problem statement you didn't describe the response message. You'll need to go through a similar exercise - tweaking and adjusting - in order to shape the response message "expected" by your client to match the responses actually generated by the real service.

Also, remember that the xmlns prefixes are not significant. It's nto the prefix you need to match, it's the XML namespace itself. You don't need STES:Execute. You can use any namespace prefix, as long as it maps to the correct xml namespace.

Good luck.

If you get a chance, convince them to move to a WS-I compliant service interface. Interop is much easier when the service complies with the WS-I recommendations.

EDIT

This is a trace of the actual message from the client, generated using that WSDL:


  
    
      00913983
      Canadian, eh?
      
      
    
    
      
      
    
    
      17
      s9dkjdls
    
    
      fish
      barrel

Even though this is different than your target message, this should be parseable by your server-side, if it conforms to SOAP v1.1 section 5 encoding spec. This request message uses the "multiple reference" serialization whereas your example target message uses "single reference". But they should be equivalent to the server side. Should be.

But as I said originally, there were lots of problems getting SOAP section 5 encoding to work interoperably.

Serialising SOAP parameters in C#

Answers (2)

Related Questions