Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Perl Programming Language

Soap/WSDL perl versus java ?


 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 ?

wbsurf@yahoo.com wrote:
>  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.

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

wbsurf@yahoo.com wrote:
>  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.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc