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.

Donate

SOAP-Lite 0.71 is available from CPAN at http://search.cpan.org/perldoc?SOAP%3A%3ALite.

0.71 is mainly a bug fix release - all users are encouraged to upgrade. The included Changes file lists the differences to previous versions.

0.71 will be the last release to run under perl 5.005 - we've decided to drop support for perls that old from the next release on. If you're using SOAP::Lite and haven't got a newer perl, you should consider upgrading now...

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...".

The SOAP protocol is a critical communication protocol on the Internet due in large part to the fact that it has become native to so many development platforms. SOAP itself has also become an incredibly stable protocol. The WS-* Wars of the early millenium seem to have died down, and the few truly useful extensions to SOAP have been selected by the market.

Most SOAP toolkits as well have stablized along with the protocol. Relative to all those other toolkits, the status of this SOAP toolkit is fair to good. It differentiates itself from other toolkits by still being really easy to use for the majority of use cases. But as more and more people adopt document-literal as their preferred method of encoding, the roots and biases of SOAP::Lite in regards to XML::RPC begin to show and the toolkit is not as resilient.

As a result, SOAP::Lite has a number of known interoperability issues with more modern implementations of SOAP servers and clients. The task of keeping SOAP::Lite up to date is a difficult one. The source code is notoriously complex, a mark of the seriously ingenious Paul Kulchenko who created SOAP:Lite. As a result baffles most inexperienced Perl programmers, and indeed sends many of them running in shear terror. I myself am given the highest respect in my office for signing up to maintain the module for this fact alone - I work with some of the brightest and most experienced Perl programmers in the industry and they all look at SOAP::Lite in awe. And not the "good" kind of awe, the kind of awe that gives people a healthy, but fearful respect.

But I am not trying to inflate my ego, I am trying to set the stage for what should be next for Perl's only SOAP toolkit.

If SOAP::Lite as a project that is to attract more contributing authors, it is essential that the SOAP::Lite code base become easier to work with. SOAP::Lite could benefit a great deal from shedding a lot of the code written before the protocol had really matured, before the era of the WS-i, before a time where other toolkits and servers had agreed upon and embraced a set of best practices. It should consider severing itself from XML::RPC which is really a different protocol that operates under a totally different set of assumptions. SOAP::Lite should shift to a document-driven model, as opposed to an RPC driven one.

Therefore SOAP::Lite needs a re-write. SOAP::Lite needs to live up the "Lite" part of its name. SOAP::Lite should be built from the ground up to conform to the WS-i's requirements. It should be built first and foremost around a wicked WSDL parser and engine. It should be made more modular so that its components can be more easily swapped out for newer and better implementations without disrupting users and developers. It should take advantage of the number of perl modules that have evolved since SOAP::Lite was conceived to reduce code complexity and obscurity.

SOAP::Lite needs your help. SOAP::Lite needs a group of 2-3 passionate people to take a fresh look at this critical toolkit for Perl developers and to usher into a new age of utilization, community growth, usage, and utility.

Undertaking a project like this is not a trivial task. It requires months and months of dedicated time and attention. And then it must also be supported and maintained.

This project would not start from ground zero. There is a vision and a plethora of tried and true code already within SOAP::Lite that shouldn't be needlessly thrown away. What we endeavor to do is make SOAP::Lite easier to grok and easier to work with. What we hope to create is a new module, called SOAP::Easy.

A year and a half ago SOAP::Lite enjoyed a frenzy of development which resulted in some critical enhancements to the platform. While a few bug reports have come in, and many have been fixed. I have held off this long for fear of a bug not yet reported, but it is important for me to remind myself that software is never finished -- it is only refined.

Therefore, I have resolved to release the latest of SOAP::Lite into the wild so that it can be used more broadly. And if issues do arise, I will take care of them.

So I have been working sith Sam Shillace over at Writely, a very cool product if no one has seen it, on problems they have been having posting against SOAP::Lite servers. Writely is one of the only successful "Web 2.0 Applications" built on top of .NET I have seen - so kudos to his and his team for proving so many people wrong that smokin' cool apps can be built on top of .NET.

Anyway that little fact is relevant because .NET has implemented a little known HTTP Header called "Expect" (officially part of the HTTP 1.1 spec) which SOAP::Lite does not support... yet.

However, I think I may have fixed that problem. I have checked in a change to HTTP.pm that I believe will do just that. It still needs to be tested, but I am keeping my fingers crossed. For you bleeding edge folks, you can check out the source code from CVS.

Found and fixed a bug at work where XMLRPC requests where being serialized using the SOAP document-literal serializer when serializing arrays.As far as XMLRPC is concerned, there is good news and bad news (I suppose). The bad news is that XMLRPC development is not really progressing that much. On the other hand, we are building out our XMLRPC unit test suite to make XMLRPC more reliable from release to release. Until this release XMLRPC simply did not work in 0.65.

A bug was discovered in all versions of SOAP::Lite 0.65 which prevented XMLRPC servers from working properly. The bug prevents incoming XMLRPC requests to be processed by the XMLRPC deserializer. Instead, the SOAP deserializer picks it up and says that the root /Envelope element cannot be found. The fix was relatively small and does not impact users of SOAP based web services - only XMLRPC based web services. But as always, everyone is encouraged to upgrade.The files have also been uploaded to CPAN, but may take 24 hours to appear there.

I have seen a lot of support requests recently asking about setting default namespaces and the like. As a result, I will be introducing some changes to the API that I believe makes this task much more intuitive. Of course, changing the API should not be done lightly, especially to a subroutine like uri which is used by every installation of SOAP::Lite on the planet - one way or another. So it will be slowly phased out. So what are these changes, you ask?

First, there are two new subroutines added to SOAP::Serializer and also made available through SOAP::Lite as a shortcut, they are: default_ns() and ns(). They set the namespace URI of a request while at the same time express how that namespace should be serialized - either as a default namespace or as a declared namespace. Second, to provide a more intuitive name, use_prefix is being deprecated in favor of one of the aforementioned subroutines. Finally, uri() is also being deprecated for similar reasons. It's name never did make that much sense to me, and I am hoping that ns() is more intuitive.