Developement work with the SOAP::Lite 0.70_xx pre-releases is reaching some point where I feel it's time for a new stable release.
I expect 0.71 to be out by the end of february 2008.
If you want to help me, you may just try out the 0.70_xx pre-releases from CPAN and report any errors you experience.
Martin
Paul has written a good guide of how to encode complex data structures and schemas in SOAP::Lite.
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.
Byrne Reese
Lead Developer and Maintainer, SOAP::Lite
I just pushed the latest version of SOAP::Lite to CPAN. It is a relatively small release containing the following fixes:
Documentation is key to any project, and readability is key to any documentation. Thus, I made a point to gift a face lift to what is quickly becoming the definitive documentation on SOAP::Lite.
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.