From the reading I've done, it seems like there is a degree of risk regardless of which SOAP stack you use, unless you can guarantee that your clients and servers are using the same one. If you have something that works sufficiently well for your target audience already, I'd be tempted to leave it as is.

The SOAP:: Lite Changes file has a fairly comprehensive list of the changes between 0.60 and 0.69 if you want to see what you may be missing out on - in particular, there seem to have been a substantial amount of changes around the 0.65 revision(s).

Hope that helps.

Hi, I am using soaplite version 0.69 without custom serializers and it works. I just create messages with SOAP::Data package. There are not many examples with soaplite and document/literal style as server. It would be grate if someone gives any examples. Regards, Ive

Untested by me (but definitely filed for further investigation): this would seem to be exactly what you're after. I'd appreciate hearing any feedback you have from this approach if you give it a go.

Hope that helps

We use SOAP::Lite (both server and client) quite extensively. Recently we upgraded to 0.69 (currently the latest version I think) and things went wrong.

Except of some inconsistencies in our code, which were tolerated by the old version of SOAP::Lite, I found two quite serious errors:

• Invalid response envelope with use_default_ns = 0 - affects server because the serializer may emit a response, which is not well formed XML.
• Namespace having prefix soap in WSDL file used in soap envelope - this one is a interesting client error, making IMHO Akar::SOAP->service unusable for most RPC/encoded WSDLs.

Nevertheless we still use 0.69, even for document/literal SOAP. To have full control over the content of soap body element I often use $soap->call with the method argument being a XML (XML::LibXML) document (complete content of the soap:Body element).

    my $som = $soap->call(soap_xml_data $xml_doc);
[download]

On the server site I use similar approach to return the complete content of soap:Body element.

    sub dispatched_method {
        ....
        return soap_response_body(soap_xml_data($xml_doc));
    }
[download]

This approach contains an ugly hack, which prevents SOAP::Lite serializer to wrap the returned value by a response element.

Since this shows up in a Google search I decided to add a more up-to-date answer.

Currently XML::Compile::SOAP will provide you with a much more feature-complete implementation of the SOAP protocol. SOAP::Lite doesn't actually implement Literal encoding so you have to go to great lengths in trying to produce the right document.