in reply to start over with SOAP in Perl?

Much of the complexity of SOAP::Lite comes from the actual SOAP specification. There's a multitude of different encoding methods, multiple transport options, different incompatible versions of XML Schema, etc. And let's not forget it has both client and server code in it.

I've read through the code, and yes, there are parts of it that are still well over my head, and it takes me a 1-5 days to get back up to speed on it when I'm trying to remember what I was doing with my replacement serializer. (I think I stared at it on and off for a month before I felt I was to the point where I could really mess with it, and I had to deal with the object methods calling functions in the same namespace, so I couldn't easily subclass the serializer)

Let's look at the questions for decision making -- does it do what I need it to do currently? Yes. Could it be improved? Probably. Have I worked around most of my problems with it? Yes. Do I have any current outstanding issues with it? No. Is it currently worth my time of trying to do a major overhaul or rewrite? Nope. Might it be in the future? Perhaps.

Are there other languages that I need SOAP support in, that I don't have it? Yes. Am I working on a SOAP client for one of them? Yes. Is it a royal *@#$^ pain? Yes. Do I have any idea what I'm doing? Not really.

As I see it, trying to understand the SOAP::Lite code is a lot less effort than a complete re-write. I don't know enough about the other SOAP toolkits from other languages to know what is, or isn't a good model. I would say, if you're going to do it, you should come up with definite reasons for doing it -- and something that can be measured ('functions well' is rather ambiguous). SOAP is a very complex concept, and it's going to be very difficult to make something that can deal with the complexity, be easy to maintain, and whatever other requirements you might have (ie, memory usage, execution speed, etc.)

Now -- as best I can tell, you've only once asked for help with SOAP::Lite here. If you have specific problems, we might be able to help you. (of course, there's also the possibility that we can't help you, but the possible good outcome usually outweighs the cost of asking).

Replies are listed 'Best First'.
Re^2: start over with SOAP in Perl?
by McMahon (Chaplain) on Aug 30, 2006 at 20:57 UTC
    The most pressing problem I have with SOAP::Lite right now is that it doesn't support complexTypes

    It also doesn't seem to evaluate input in boolean context appropriately, but that could be related to the lack of complexType support: all of my boolean values are used in complexType functions.

    I have also seen what seems to be a pretty evil bug when sending non-ascii characters like è or à, where the entire message gets encoded in what seems to be base64.

    And even a cursory look at the SOAP::Lite mail list is a source of myriad other bugs and problems.

    For myself, I had enough some time ago, I'm using Ruby. But I'm trying to make some great customers happy by getting to the bottom of the problems we're having with SOAP::Lite. It's hard enough just defining the problem. But there are some fairly serious Perl programmers at my company, and none of them are willing or able to tackle the problems with SOAP::Lite.
      The most pressing problem I have with SOAP::Lite right now is that it doesn't support complexTypes

      Elaborate on 'doesn't support ComplexTypes'. I pass through rather complex structures, and it handles them just fine. It doesn't support auto-generation from WSDL for them, and it adds some random 'gensym' elements all over the place if you try to return a complex perl data structure to it, but it is possible to pass ComplexTypes with SOAP::Lite.

      It also doesn't seem to evaluate input in boolean context appropriately, but that could be related to the lack of complexType support: all of my boolean values are used in complexType functions.

      You have to use SOAP::Data to cast things to boolean. It can't tell if you mean 'false' as a string, or as a boolean. Deserializing should be fine, but the serializer makes a whole lot of guesses about what it sees, if you don't wrap stuff w/ SOAP::Data. (and it's frequently wrong, for the data I have ... eg, I send timestamps as a string field, eg '20060101000000' ... which matches the rules for float, so gets encoded as such unless I tell it otherwise.

      I have also seen what seems to be a pretty evil bug when sending non-ascii characters like è or à, where the entire message gets encoded in what seems to be base64.

      That's not a bug. It's a feature. Look at SOAP::Serializer ... in Autotyping, 'base64' has the highest precidence. base64's match criteria is:

      base64 => [10, sub {$_[0] =~ /[^\x09\x0a\x0d\x20-\x7f]/}, 'as_base64'],

      If you prefer, you can place something at precidence 5 (or anything lower than 10), that will match your cases, and send it to 'as_string' or your prefered function.

      And even a cursory look at the SOAP::Lite mail list is a source of myriad other bugs and problems.

      Yep. If you manage to find a non-trivial software package with absolutely no bugs or problems, let me know, because I don't think they exist. (unix's 'yes' qualifies as trivial)

      there are some fairly serious Perl programmers at my company, and none of them are willing or able to tackle the problems with SOAP::Lite.

      That's probably for the best -- you'll melt your brain trying to understand what's going on. It's not something to be attempted lightly.

      For all of its failings, SOAP::Lite can be made fit most problems. I'm not going to claim all, because SOAP is not an easy subject. If you have specific problems, there's a good chance that someone out there can help you, but it's not going to be a free ride -- expect there to be some pain. Much of the problem isn't with SOAP::Lite, but with SOAP in general, and the varying implementations across toolkits.

        ...it adds some random 'gensym' elements all over the place if you try to return a complex perl data structure to it...

        ...if you don't wrap stuff w/ SOAP::Data. (and it's frequently wrong...

        ...That's not a bug. It's a feature. Look at SOAP::Serializer ... in Autotyping, 'base64' has the highest precidence. base64's match criteria is:
        base64 => [10, sub {$_[0] =~ /[^\x09\x0a\x0d\x20-\x7f]/}, 'as_base +64'],


        ...it's not going to be a free ride -- expect there to be some pain. Much of the problem isn't with SOAP::Lite, but with SOAP in general, and the varying implementations across toolkits.



        You're making my point better than I ever could. None of these sorts of issues seem to exist in the SOAP client libraries of the other four languages that my company deals with on a regular basis: Java, PHP, Ruby, or C#. All of these languages seem to handle complexTypes, booleans, encodings, data types, etc. with a minimum of fuss and bother. Only Perl seems to require the melting of brains.

        I wrote about my experience with the Ruby and other languages' SOAP libraries, if you'd like to read about a comparable experience.

        For all I know, my company's customers are out there solving these problems for themselves right now, but if they are, they are awfully quiet about it. Three of us at my company have been spending time trying to come up with some sort of concrete recommendation besides "abandon the WSDL; hack the serializer; don't bother with the mail list."