I've successfully used POD::WSDL to generate WSDL using Perl 5.8.x.
> We need to develop a SOAP service on appache. Java axis 2 with Resin
> seems like what we should do, however I was wondering if doing this
> in Perl might be a good idea ? I did see that the WSDL generator on
> CPAN says it does not work in Perl 5.8 because of autoload problem in
I've used that generated WSDL to create C# client stubs for Perl
web-services. I had to edit two of the namespace definitions though
I'm not sure if I could have avoided this by configuring POD::WSDL or
SOAP::Lite to use consisten namespace values.
> I know that when I had to support an XML parser in Java, it My limited experience of web-services in Perl and Java suggests that
> seemed complex and the same Perl parser would have been perhaps 5
> times less code. Since there will not be much more than 1000 lines of
> Perl code, any maintenance issues would not be a big problem.
Perl can be an order of magnitude simpler to code. But it depends.
Marshalling complex objects seems slow in Perl (SOAP::Lite) but I've not
benchmarked it against Java. I think Java (6) really starts to win out
if you have to deal with digitally signed SOAP messages.
Since web-services in Perl means SOAP::Lite, the RPC/Encoded vs
Document/Literal issue may be something to consider if you *must*
generate a Doc/Literal service (though I suspect Doc/Literal-Wrapped can
be, er, simulated, using SOAP::Lite).
If you have complex payloads then Perl SOAP::Lite is least work if you
return properly constructed Perl objects. Constructing return values
using SOAP::Data gives you a lot of flexibility but is more work. I was
forced to do this to make the serializer consistently tag data types
(string, integer ...) instead of guessing based on value, some non-Perl
clients don't like it when a string "1" is given an "int" attribute :-)
At the moment, I'd prefer Perl for web-services of low to medium
complexity where the throughput is not high.
If I was more proficient in Java, I suppose my view might change.