I have to agree with you. SOAP::Lite sucks. I think it's mainly because the whole protocol sucks, but ... well I wish there was some brave and determined soul who'd spend a year or two in the SOAP (Simple Object Access Protocol? My foot!) land and came back scarred, but victorious with something that works (for the best definition of "works" allowed by the protocol). :-(

I'm afraid it can't be me. For now if I have to do something with SOAP and can't make it with XML::Simple/XML::Twig for parsing and filling in the template I extract from an example XML, I think I'll have to delve into .Net, use some C# (hopefully mostly generated) and use it via PerlNET.

Interestingly, this anon "troll" noticed that you used to have the signature saying something like "XML sucks, but SOAP rocks", now that sig is gone, and you seemed to have some issue with SOAP. It would be useful, if you can point out couple of things here what you don't like about SOAP.

p.s. Although part of the issue with SOAP::Lite could be blamed on SOAP, but not everything.

that you used to have the signature saying something like "XML sucks, but SOAP rocks"

the sig said:
XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.
take your time.

update
PS: I scribbled down some notes (Windows .doc) on calling a .NET generated WS from Perl (using SOAP:Lite) some time ago, - at the very basic "Hello world" level.
Send me your email, if you'd like a copy.
Best regards,
Allan Dystrup
and@kmd.dk

Actually the stub maker is a quite decent job if SOAP::Lite works. It made you really feel that you are calling the remote service as a method call, and you don't see the XML or SOAP. But unfortunately SOAP::Lite does not work (and the code the stub maker generates is based on SOAP::Lite).

I've also found it frustrating getting SOAP::Lite to work with services not made with SOAP::Lite. If you're really interested in getting it to work from Perl, you should read the 'INTEROPERABILITY' section in SOAP::Lite's documentation. My problem with getting it to work with .Net (I know you're using Java, not .Net) was more in terms of getting the developer writing the service to give a clear example of how the service is actually called with XML, rather than code examples in VB. Given some actual XML sent to the server, it's pretty easy to get SOAP::Lite to work right.

Just for your information, your articles do seem a bit trollish. If that's your intention, then carry on, but otherwise you might want to sign up for an account. Some people ignore Anonymous Monk (I often do).

I have an account, but I often forget to log in... today I have answered a couple questions as anon...damm

Actually the code generated by the stub maker tells pretty much everythign you want to know as how to call the service. Well the bottom line is that the generated code has to work ;-).

As whether it was trollish, it is not to my standard, but I don't feel the need to be nice either. If I really want to be trollish, I don't need to be anon, I can create an account, and use it fully for trolling. What's the difference. The word troll has been over used. Anything harsh is called trolllish.

I guess fully should read solely ;-)

I found SOAP::Lite::Simple helpful in this respect. It learnt me a few tricks in dealing with the SOAP::Lite data structures, as well as figuring out what exactly the other side of the wire is expecting.

I'm not entirely convinced that the blame falls solely on SOAP::Lite, even though namespace support is not that great. The biggest problem with SOAP, in my opinion, is the protocol, and the fact that it works through XML wrappers. That means there are countless ways of screwing up, or "enhancing the protocol", simply by requiring a certain syntax for attributes, parameter types, etc.

One example I just ran into is this:

use SOAP::Lite;
my $client = SOAP::Lite->new;
$client->soapversion('1.1');

my $code = $client->service($WSDL_URL);
my $result = $code->someMethod( $someParam );
[download]

Possible SOAP version mismatch: Envelope namespace http://schemas.xmls
+oap.org/wsdl/soap/ was unexpected. Expecting http://schemas.xmlsoap.o
+rg/soap/envelope/.
[download]

Using straightforward code like the following works fine, on the other hand:

my $soap = SOAP::Lite
         ->uri($uri)
         ->proxy($proxy)
         ->on_action( sub { return $uri . '/' . $method } );

my $result = $soap->$method( SOAP::Data->name( someParam => $some_valu
+e ) );
[download]

use SOAP::Lite ( +trace => 'all', readable => 1, outputxml => 1, );
[download]

I take it you are the author of Problem with combination of SOAP::Lite and Apache AXIS2, as I pointed out in that thread, SOAP::Lite does have difficulty with the WSDL generated for an Axis2 service but that can be worked around quite simply as I showed, it is perfectly possible to call the Axis2 getVersion service from SOAP::Lite and for whatever reason you weren't able or prepared to get it to work.

You seem to be refering to the shortcomings of Perl and SOAP::Lite with regard to SOAP interchangeably, but the bottom line is that perl knows nothing about SOAP and any support must come from a module such as SOAP::Lite, so any failing is in the module, not the language itself, it would be the same if we were talking about CORBA or EDIFACT, and the same is true of Java which requires an external library such as Axis to deal with web services.

SOAP::Lite certainly does have its shortcomings, not a few of which are related to its ability to handle WSDL in all possible cases, but of course it's entirely possible that the author of the module was either unaware of these cases (which I think is possibly quite likely with the Axis2 WSDL I've seen) or there have been higher priority things to implement, either way a bug report with an indication of the WSDL that isn't working properly to the author is far more likely to get results than moaning about it here, which doesn't really serve any purpose whatsoever.

/J\

You are right that language and packages are two things, but that's only half of the story.

A language without nice extensions (packages in special functional areas) is not much useful, this is not the COBOL era. The same goes to Java, C#, Ruby or whatever. In this sense, I am not particularly mean to Perl.

In other words, you're not being interesting because your story isn't more than "I used a perl module that isn't part of the base distribution to do $notoriously_complicated_action and it didn't work".

Do: Send a bugreport or at least give us some insight in what's going wrong.

Don't: bitch about people not wanting to hear your bad news.

It'll make your stay here more productive and friendly, though I don't know if that's what you actually want.

You do realize, of course, that SOAP::Lite is, as its name implies, "lite"? Trouble with SOAP::Lite could very well be that you need to do something with your SOAP/WSDL service that SOAP::Lite doesn't handle well.

But, then, all you tried was SOAP::Lite before saying "Perl SOAP support is kinda stopped at the basics" -- seems like your skills and attitude are somewhat in question here. Did you maybe consider using the full SOAP modules instead of trying to "get by" with SOAP::Lite?

Sorry if that seems a little harsh, but when you say things like "I know that nobody here want to hear the downside of Perl, but as you can see, I am telling the story as it is", you're going to get that reaction for two reasons:

1. Lots of people hear are willing to discuss the weaknesses and shortcomings of Perl itself and of various modules on the CPAN, and
2. Problems with 3rd-party modules, like the majority found on the CPAN, are not problems with Perl; your statement belies a lack of any serious history with Perl or the community.

Further, you haven't given us any reason to believe that the problem isn't you. For example, did you ask for help? What did you do that didn't work? What's your definition of "didn't work"? Did you consider that the problem might not be SOAP::Lite or Perl, per se, but confusing documentation or some other issue?

Simply ranting about an experience you had where a module didn't work for you -- without any of the details, any history, etc. -- and then condemning the entire Perl language (on a Perl forum) based on that smells like a troll. If it wasn't supposed to be a troll, ok, but I have to wonder what's productive about complaining when you don't provide any details that would let anyone help resolve that complaint...

Now have one day of experience. Come back with one more comment: as Ruby is more OO, it matches with server side code very nicely. When I tried to call a service that requires an object as parameter, the ruby knows that, and forced me to create a ruby class that matches the java class. Nice!

By object, do you just mean a complex type? AFAIK, the SOAP protocol doesn't actually support passing objects in any real sense.

That is true, but there is also the other side of the story.

As an end user, when you call web service, you don't care whether SOAP is behind everything (although you know that for a fact, but you don't care). All you care is that you are calling a function or a method, whatever how you call it. Obviously you can paa an object to the call (and you don't care how it is marshalled).

One of my web service call accept an Pair object, and return a different Pair object (Pair is nothing more than a pair of interger and bunch of methods), and the server side is in java. When I call it from Ruby, I can define a similar class on the client (in Ruby), and send and receive the Ruby Pair object, as if it is a Java Pair object. That's really handy, makes lots of sense.

When I use SOAP::Lite, I have to treat the object as a hash, which is not a big deal, if the namespace was not mishandled.