SOAP - INTEROPERABILITY

INTEROPERABILITY ^
Microsoft .NET client with SOAP::Lite Server

In order to use a .NET client with a SOAP::Lite server, be sure you use fully qualified names for your return values. For example:

  return SOAP::Data->name('myname')
                   ->type('string')
                   ->uri($MY_NAMESPACE)
                   ->value($output);

In addition see comment about default encoding in .NET Web Services below.
SOAP::Lite client with a .NET server

If experiencing problems when using a SOAP::Lite client to call a .NET Web service, it is recommended you check, or adhere to all of the following recommendations:

Declare a proper soapAction in your call

    For example, use on_action( sub { 'http://www.myuri.com/WebService.aspx#someMethod'; } ).
Disable charset definition in Content-type header

    Some users have said that Microsoft .NET prefers the value of the Content-type header to be a mimetype exclusively, but SOAP::Lite specifies a character set in addition to the mimetype. This results in an error similar to:

      Server found request content type to be 'text/xml; charset=utf-8',
      but expected 'text/xml'

    To turn off this behavior specify use the following code:

      use SOAP::Lite;
      $SOAP::Constants::DO_NOT_USE_CHARSET = 1;
      # The rest of your code

Use fully qualified name for method parameters

    For example, the following code is preferred:

      SOAP::Data->name(Query  => 'biztalk')
                ->uri('http://tempuri.org/')

    As opposed to:

      SOAP::Data->name('Query'  => 'biztalk')

Place method in default namespace

    For example, the following code is preferred:

      my $method = SOAP::Data->name('add')
                             ->attr({xmlns => 'http://tempuri.org/'});
      my @rc = $soap->call($method => @parms)->result;

    As opposed to:

      my @rc = $soap->call(add => @parms)->result;
      # -- OR --
      my @rc = $soap->add(@parms)->result;

Disable use of explicit namespace prefixes

    Some user's have reported that .NET will simply not parse messages that use namespace prefixes on anything but SOAP elements themselves. For example, the following XML would not be parsed:

      <SOAP-ENV:Envelope ...attributes skipped>
        <SOAP-ENV:Body>
          <namesp1:mymethod xmlns:namesp1="urn:MyURI" />
        </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

    SOAP::Lite allows users to disable the use of explicit namespaces through the use_prefix() method. For example, the following code:

      $som = SOAP::Lite->uri('urn:MyURI')
                       ->proxy($HOST)
                       ->use_prefix(0)
                       ->myMethod();

    Will result in the following XML, which is more palatable by .NET:

      <SOAP-ENV:Envelope ...attributes skipped>
        <SOAP-ENV:Body>
          <mymethod xmlns="urn:MyURI" />
        </SOAP-ENV:Body>
      </SOAP-ENV:Envelope>

Modify your .NET server, if possible

    Stefan Pharies <[email protected]>:

    SOAP::Lite uses the SOAP encoding (section 5 of the soap 1.1 spec), and the default for .NET Web Services is to use a literal encoding. So elements in the request are unqualified, but your service expects them to be qualified. .Net Web Services has a way for you to change the expected message format, which should allow you to get your interop working. At the top of your class in the asmx, add this attribute (for Beta 1):

      [SoapService(Style=SoapServiceStyle.RPC)]

    Another source said it might be this attribute (for Beta 2):

      [SoapRpcService]

    Full Web Service text may look like:

      <%@ WebService Language="C#" Class="Test" %>
      using System;
      using System.Web.Services;
      using System.Xml.Serialization;

      [SoapService(Style=SoapServiceStyle.RPC)]
      public class Test : WebService {
        [WebMethod]
        public int add(int a, int b) {
          return a + b;
        }
      }

    Another example from Kirill Gavrylyuk <[email protected]>:

    "You can insert [SoapRpcService()] attribute either on your class or on operation level".

      <%@ WebService Language=CS class="DataType.StringTest"%>

      namespace DataType {

        using System;
        using System.Web.Services;
        using System.Web.Services.Protocols;
        using System.Web.Services.Description;

       [SoapRpcService()]
       public class StringTest: WebService {
         [WebMethod]
         [SoapRpcMethod()]
         public string RetString(string x) {
           return(x);
         }
       }
     }

    Example from Yann Christensen <[email protected]>:

      using System;
      using System.Web.Services;
      using System.Web.Services.Protocols;

      namespace Currency {
        [WebService(Namespace="http://www.yourdomain.com/example")]
        [SoapRpcService]
        public class Exchange {
          [WebMethod]
          public double getRate(String country, String country2) {
            return 122.69;
          }
        }
      }

Special thanks goes to the following people for providing the above description and details on .NET interoperability issues:

Petr Janata <[email protected]>,

Stefan Pharies <[email protected]>,

Brian Jepson <[email protected]>, and others

 

source: http://search.cpan.org/~phred/SOAP-Lite-1.20/lib/SOAP/Lite.pm#INTEROPERABILITY