First I used SOAP::Lite to do my requests, but I found it confusing to construct the requests that I needed to make. I even discovered a bug that lead to the current ( 0.714 ) release of SOAP::Lite.
Next I started using SOAP::Data::Builder to make it easier to build my SOAP::Lite requests. This was good, but frustrating that I had to add my data in a specific order.
Finally I came upon XML::Compile::SOAP. A glance at it's API which used a hash to build requests seemed much better. however, it took me a few weeks and some help from Mark Overmeer (the author) and an update to XML::Compile::SOAP::WSS to get it to work.
If you're planning on starting a new project that requires SOAP I definitely recommend using XML::Compile::SOAP if you have a
.wsdl and a .xsd to work with.I will be covering all 3 of these methods in Parts 1, 2 and 3 of the series.
To get started we'll need a SOAP Server since I haven't been able to find any reliable public services. To do this you can install XML::Compile::SOAP::Daemon (which probably could use some Plack/PSGI love ). You'll also want to download it's tarball directly, extract it and
cd examples/namesservice. Once you've done that you can do perl server.pl . Now you should have a Server running on http://localhost:8877 which we can use for testing our client examples.Please be advised, these tutorials will not be explain XML, XSD, WSDL, or SOAP, but simply the Perl interfaces.
I used SOAP::Lite, but there is something special on it. The way you call the method.
ReplyDeleteAt beggining, it was difficult, but later, after knowing that are different ways to call, it become easy.
well I now have experience with 3 different ways of doing things... so I'll be documenting that. Part of my problem with SOAP::Lite was certainly the bug that I got fixed in 0.714.
ReplyDeleteI have to agree with you, XML::Compile rocks. I've used it to talk to Microsoft Exchange Web Services without issue. But the docs are dense for the newcomer, so thanks for taking the time to blog about this.
ReplyDeleteI found the same things using all three libraries listed. The big problem with SOAP::Lite as you stated is building data to send and receiving data and turning them into native Perl data structures properly. It's just *super* painful with SOAP::Lite especially when you are dealing with complex objects (which is almost all the time nowadays). In addition I found the documentation confusing. As you stated SOAP::Data::Builder helps but not enough.
ReplyDeleteWhen XML::Compile::SOAP first came out I was like yeah! finally a library that knows how to automatically build and receive data structures without me having explicitly spoon feed it, which is the way it should be for most cases.
From my experience (most writing clients with WSDL files) one thing I found better with SOAP::Lite compared to XML::Compile::SOAP, if you exclude all that nasty data building stuff, is the syntax can be cleaner sometimes. For example, you can instantiate a service object with the ->service() method which takes the WSDL URL and then that service object has all the service methods and knows what parameters you have to pass. With XML::Compile::SOAP you have to do more steps.
Until SOAP::Lite improves its way of dealing with data I would totally recommend XML::Compile::SOAP as the default library to use on CPAN. What would be very cool is if something like Moose or other Perl object system could be incorporated into one of these SOAP libraries so that one can get and receive real objects instead of nested hashrefs etc.