in reply to Re^2: start over with SOAP in Perl?
in thread start over with SOAP in Perl?

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.

Replies are listed 'Best First'.
Re^4: start over with SOAP in Perl?
by McMahon (Chaplain) on Aug 31, 2006 at 15:11 UTC
    ...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'],

    [download]


    ...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."
[reply]
[d/l]

      The only fair comparison is PHP -- the other languages track information about what the type of the variables are, which is where SOAP in perl falls down. Perl is not a strictly typed language, and so SOAP::Lite tries to guess what you intended.

      Sometimes it's right, sometimes it's not. Just like Perl -- sometimes the DWIM doesn't work. Perl has no concept of a boolean type, nor easily discernable differentaton between a float, integer and string -- they're all just scalars. As for the gensym bits, it's because it has no element name to use, because of the way arrays and hashes are handled in Perl. You don't need named structures, like some other languages. So it randomly inserts something for you. Is that the best solution? Maybe. Perhaps it should have a 'strict' option where it dies anytime it has to make an assumption about what you wanted, so you could see where you didn't cast every last item that might be ambiguously interpreted

      And I don't think I ever said abandon the WSDL -- in fact, if you check the soapbuilders list, I believe that the general concencus is to use the WSDL as a starting point, but not necessarily as-is -- copy it, modify it to work for your toolkit, and point to that. The problem is if the server should change their WSDL, but odds are, that'd break things anyway.

      And you don't have to hack the serializer if you follow the instructions in the SOAP::Lite documentation for casting data using SOAP::Data. I don't have that luxury, because I have a SOAP aggregator, which gets its data from a SOAP server, and passes it back out, so it was easier to hack the Serializer. There are methods to give extra conditions or change the precidence of items -- use it, it's what they're there for.

      Personally, I'm working on moving all of my services over to document/literal, rather than rpc/encoded. Of course, I have the advantage that I control all of the servers (but not all of the clients)

[reply]

      I agree that the way to fix SOAP::Lite is to replace it. This is not to say SOAP::Lite is not an excellent package or the people who built it didn't do us all a great service. But replacing one component with a new one, and new ideas, is a time-honored tradition that works in the Open Source world.

      What should the SOAP::Lite replacement look like?

      • It should make the easy things easy and the hard things possible.
      • It should be as clean and satisfying for a Perl fan to use as the Ruby, Java, etc. approaches are satisfying to users of those languages.
      • It should do everything the SOAP standard demands, including complex types.

      If anyone wants to kick off a mailing list, or SF project, or anything else to make progress on these goals, please let me know.

[reply]
      Have you considered taking the Ruby or PHP SOAP library and porting it to Perl?
[reply]
        easyer still ... well maybe ;)
        Inline::Ruby



        This is not a Signature...
[reply]
[d/l]

In Section Meditations