I was testing the 2.0 version of SOAP::WSDL, so I have an idea about what it can do. That version doesn't use SOAP::Lite under the covers (though it emulates the API to a degree) hence my comment. :-) One thing I immediately ran into with SOAP::WSDL was the need to combine my definitions, schema, and service files into 1 (which took <5 min to fix a couple namespace definitions). After that it ran and was able to generate both the client and server perl modules. XML::Compile processed my wsdl definition fine once I told it about where the other 2 were, so it handles the <import> but simply chooses not to be network aware. The author mentions this as a design decision in the docs.

What wasn't immediately obvious to me was how I would use those resulting classes on the server side. If I understand things correctly, I could use the Interface class and go from there.

One the one hand I do like that it autogenerated all the code & modules for me. But I wonder about the possible overhead that creates (perhaps none?). I know that XML::Compile takes a completely different approach to the efficiency problem by parsing the WSDL and returning a code ref for each operation (my $call = $wsdl->operation('MyFoo'); IIRC). The idea there was to call operation() once and save the resulting object. If you're getting a fresh object every time then clearly that approach will not scale like SOAP::WSDL.

Benchmarking SOAP::WSDL and XML::Compile::WSDL11 using their optimum setup environment would be my next step if I had the time. :-)