SOAP::Lite for Perl is a collection of Perl modules which provides a simple and lightweight interface to the Simple Object Access Protocol (SOAP, also known as Service Oriented Access Protocol) both on client and server side.
Byrne and others have posted some good
stuff (see for example the majordojo soaplite archive and this hands-on tour
at builder.com), but mostly you'll find the experiences shared go along
lines like "...after hacking around for a bit, I found that this
worked...".
I spent some time this weekend going through SOAP::Lite bugs, and I am so impressed with the S::L developer community! Almost all of the bugs contain patches of some kind. I can't tell you how wonderful it is (as the developer on a project like this) to have your users essentially doing your job for you! So thank you.
But that is not the point of this post. In one of the bugs a user, Michael Douglass to be exact, submitted what appears to be an improved implementation of SOAP::Transport::HTTP::Daemon. I am not ready to include the code in 0.65, but thought I would share it with the community and see if I can't get it to endorse it somehow so that I might include it in a later release.
I will test it eventually, but I am focusing on 0.65_3 right now and don't have the bandwidth for new features like this. Furthermore, I tend to avoid writing an HTTP daemon in Perl when I can use Apache for free. I would be curious to know why so many SOAP::Lite developers like using their own home grown HTTP daemon when there are so many good free ones available. Anyone care to shed some light on this?
I had no idea what I was getting myself into when I said I would take the reigns of the SOAP::Lite project. SOAP::Lite is an extensive module that feels like it grew quite organically. It is infused with some of the most creative Perl I have ever seen, and it took me two years of sporadic and at times intense development to even begin to unravel and make sense of the code. As a result, most SOAP::Lite releases have focused on areas of code which I was already intimately familiar, i.e. the MIME section, or with relatively minor bug fixes. But with 0.65 I pledged to tackle some of the issues that have long frustrated me. Over the next couple of weeks I will introduce a series of articles that explores some of the enhancements I have made to SOAP::Lite 0.65.
A common question in the SOAP::Lite Newsgroup is about intercepting the request prior to handling, and the response prior to it being returned. SOAP::Lite v0.65 enables this on the client side pretty easily using the http_request and http_response methods on SOAP::Transport::HTTP::Client, but the server side is still a relative black art. I have friends who have used SOAP::Trace to log, or write to a file, the SOAP payload, but that is not entirely sufficient for all their needs. In future versions, SOAP::Lite will introduce the concept of handler chains, similar to Java Servlets, but for now, one still needs to do a little more work. The following code sample shows how one can extend SOAP::Transport::HTTP:CGI to intercept both the HTTP request and the HTTP response prior to it being processed and/or returned respectively.
Well behaved SOAP services must persist and proxy SOAP headers not addressed to them. Unfortunately, SOAP::Lite does not do this for you automatically, so you must do it yourself. You can find a a little write up on how here.
I recently participated at Salesforce's dreamForce conference teaching developers about how to use SOAP::Lite to call Salesforce's new APIs. The code samples and modules I created for them can now be found at Sourceforce. The code samples were derived from the code generated by wsdl2perl, an ongoing development effort that aims to make WS programming even easier using Perl.
Recent Comments