Re: State of SOAP/WSDL support

SOAP::WSDL is currently undergoing a substantial upgrade. Version 2.00 is available as a “developer release.” (Which means that you must ask CPAN to install the .gz file instead of simply using the package-name. This is described in perldoc CPAN.)

This new version appears to be extremely powerful and complete, and while I did encounter right-away a very complex WSDL schema that it didn't understand, the developer immediately began working on the issue and now reports that he has resolved this in the SVN version. (I haven't pursued it yet.)

The general strategy of “compiling” seems to be a good one, for efficiency reasons, as it is (relatively speaking) time-consuming to process a WSDL. (This strategy auto-generates Perl code and data-structures which conform to the intended format.)

It is interesting that you decry SOAP::Lite because, as far as I know, SOAP::WSDL is built on top of it. Benchmarking your proposed strategy under real-world load conditions is obviously critical but you've clearly got a good grip on that.

Replies are listed 'Best First'.
Re^2: State of SOAP/WSDL support by drewbie (Chaplain) on Feb 26, 2008 at 22:16 UTC
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. :-)	[reply]

Replies are listed 'Best First'.

Re^2: State of SOAP/WSDL support
by drewbie (Chaplain) on Feb 26, 2008 at 22:16 UTC

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. :-)

[reply]