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
5.8. I know that when I had to support an XML parser in Java, it
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.
Also the client side is PHP, does that make any difference ?
Arne Vajhøj - 25 May 2007 22:48 GMT
> 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
[quoted text clipped - 4 lines]
> 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.
I prefer Java for Perl, but I am a Java programmer - if you ask a
Perl programmer he will prefer Perl, so that does not help you much.
> Also the client side is PHP, does that make any difference ?
No.
Arne
RedGrittyBrick - 26 May 2007 16:18 GMT
> 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
> 5.8.
I've successfully used POD::WSDL to generate WSDL using Perl 5.8.x.
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
<wsdl:definitions ...
xmlns:tns1="http://namespaces.soaplite.com/perl">
...
<wsdl:types>
<schema targetNamespace="http://namespaces.soaplite.com/perl"
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
> 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.
My limited experience of web-services in Perl and Java suggests that
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.