In general found SOAP::Lite does a good job, including WSDL support - it's been possible to do everything I needed to with it, such as hooking up to a fairly complex webmethods Java service. I haven't found any significant shortcomings in terms of what it supports but if you have anything unusual about the service you are accessing, you have to get familiar with the source - learning curve. Oh - and you need to have a pretty good understanding of SOAP and WSDL (e.g. you can interpret the raw XML).

The only gripe I have is it hides LWP too much - it's hard to get decent HTTP debugging out of it.

Think the problem isn't so much SOAP::Lite but rather that SOAP itself is a joke - way too complex - designed by committee, supporting use cases that will only ever exist for 0.0001% of it's users. And it's a protocol on top of a protocol (HTTP normally) - that already makes for a debugging / testing disaster.

In practice, writing a new library to support everything SOAP + WSDL does is going to be a ton of work.

It's summed up nicely here:

(...) enterprise developers working for government agencies and businesses who see all the success that Web companies are having with simple technologies like RSS and RESTful web services while they have difficulty implementing SOAs in their enterprises for a smaller audience than these web sites. The lesson here is that all this complexity being pushed by so-called enterprise architects, software vendors and big 5 consulting companies is bullshit.

Where to begin. Too much to say.

Think the problem isn't so much SOAP::Lite but rather that SOAP itself is a joke - way too complex - designed by committee, supporting use cases that will only ever exist for 0.0001% of it's users.

SOAP is an RPC-esq way of doing message passing in a language agnostic way. The intention, I believe, is to cover all bases. It covers message passing, attachments, object description so to speak and a few other nifty things. It's the protocol of which I speak, not the implementation. Some languages have botched libraries. Just like some car makers can't make a decent vehicle to save their life. (Not entirely true :) Also, SOAP 1.0 had its issues, 1.1 solved a few and they are still working on it. The technology is still quite young, especially in comparison to HTTP, as an application level protocol. It covers a lot of bases on purpose so one does not resort to stupid hacks. Any good architecture will allow for enough flexibility so one can work, the tools to facilitate that, but not enough to hang yourself by.

And it's a protocol on top of a protocol (HTTP normally) - that already makes for a debugging / testing disaster.

Wrong. It's a format protcol, so to speak. It's a method of formatting a messgae call, or a function call which is a fancier message call. It's like pairing the POP protocol to the mbox format. You CAN use the maildir format w/ pop. Frequently, people don't. Which is annoying. Quite.

Anyway, architects do like it in respect to working over long relationship distances: between departments that do not work closely or between companies. In the end, it is nice because it is a common protocol with tools written around it that save a lot of time. I don't have to worry about the underlying protocol, so long as my language can handle it. HTTP is the default since it's by far the simplest for synchronous message passing. It can be communicated by SMTP, FTP and SCP asynchonously.

Look at it like this. REST is simple. You need to usually develop your own library to access a REST service, but the REST service is fairly well documented if it is in any way popular. I'd argue PM's XML format to be like that, once you find the docs. :) Anyway, you have to relearn how someone implements rest. Speaking of which, you argue that SOAP is done over HTTP by default. What do you think REST services tend to be written over? :)

SOAP is simple for those who know SOAP. People who know SOAP know what NOT to do, and what TO do to make working easy. People, including myself, have the tools to takea WSDL (Soap descriptor) file and turn it into a stub in minutes, w/ far less reading to do and less code to write. It's the ability for a person to go from one SOAP shoppe to another, or for one SOAP user to use many shoppes at once, w/o relearning SOAP, is its power.

Look at it like this. REST is simple. You need to usually develop your own library to access a REST service, but the REST service is fairly well documented if it is in any way popular. I'd argue PM's XML format to be like that, once you find the docs. :) Anyway, you have to relearn how someone implements rest. Speaking of which, you argue that SOAP is done over HTTP by default. What do you think REST services tend to be written over? :)

I don't view REST as being written "over" anything; rather, it's using HTTP to a fuller extent. For instance, a web service may require user/pass authentication. Many of them do it something like this:

GET /path/to/service?user=foo&pass=bar HTTP/1.1
Host: foobar.com

HTTP/1.1 200 OK
[other headers]
Content-Type: text/plain

Error: Username/password invalid
[download]

This was acceptable practice back when CGIs were the standard. These days, mod_perl (and equivilents for other languages and servers) let us hook into the server more deeply, including taking over the authentication layer, so we can handle authentication using the headers HTTP already has:

GET /path/to/api?name1=value1&name2=value2 HTTP/1.1
Host: foobar.com
Authorization: Basic Zm9v0mJhcg==

HTTP 401 Unauthorized
[Other headers]

[Optional return data]
[download]

The advantage here is that you often don't have to write a new library, at least for these common things. LWP::UserAgent (and other WWW libaries) already knows how to do HTTP basic and digest authentication, and its is_success() method should return false for a 401 HTTP response.

The more complex parts of your application will always require code, of course, but letting HTTP handle the things HTTP knows how to handle means that you can focus on the harder bits.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Have to dispute some things...

SOAP is an RPC-esq way of doing message passing in a language agnostic way.

...except when it isn't, such as when document/literal encoded - reasonable description here.

The intention, I believe, is to cover all bases.

There in lies the whole problem - design by committee. Many of the use cases were fantasy - something vendors where / are hoping to sell in the SOA orgy. That's compared to REST, which was an abstraction principles and experiences gained with HTTP and what went before it - specifically REST isn't trying to be a one size fits all - Roy Fielding explicitly describes the things it's bad at.

Wrong. It's a format protcol, so to speak. It's a method of formatting a messgae call, or a function call which is a fancier message call.

So what's the addressing scheme for? And how did we get to HTTP over SOAP?. Also document / literal style services aren't about calling remote APIs - what you describe is only a subset of SOAP - Encoded / RPC over HTTP.

SOAP is simple for those who know SOAP. People who know SOAP know what NOT to do, and what TO do to make working easy. People, including myself, have the tools to takea WSDL (Soap descriptor) file and turn it into a stub in minutes, w/ far less reading to do and less code to write. It's the ability for a person to go from one SOAP shoppe to another, or for one SOAP user to use many shoppes at once, w/o relearning SOAP, is its power.

I know where you're coming from but in the end that's the illusion of SOAP - it feels good when everything "just works" like this. But the moment it doesn't, you got a huge stack of code to debug + verbose wire formats (can you do XSD by hand?). And with networks involved, there are a lot of things that can go wrong. And have mercy the moment you need to scale to anything but low volume Intranet / Extranet interfaces...

All I can do is express the opposite point of view with the following code;

#!/usr/bin/perl -w
use strict;

use Carp;
use LWP::Debug qw(+ -conns);
use LWP::UserAgent;
use XML::Simple;
use Data::Dumper;

my $ua = LWP::UserAgent->new;

my $res = $ua->get('http://perlmonks.org/?displaytype=xml;node_id=3333
+');

if (!$res->is_success) {
    croak("Failed!\n".$res->as_string);
}

print Dumper XMLin($res->content);
[download]

It's got error handling, a trace of the "raw" HTTP conversation and it gives you an instant data structure to examine. It's relatively easy to extend this to support conditional GETs and you're already on your way to preserving bandwidth / scaling.

We can argue the ins and outs of this ad infinitum but from my perspective, simple always wins.

After using SOAP libraries in Java, C#, Ruby, PHP, and Perl, I have found by any empirical measurement that Perl is by far the worst. I have to say that I think this is damning with faint praise:

"...but if you have anything unusual about the service you are accessing, you have to get familiar with the source - learning curve. Oh - and you need to have a pretty good understanding of SOAP and WSDL (e.g. you can interpret the raw XML)."

This kind of hacking is unnecessary in the SOAP libraries of the other languages I mention.

*Of course* writing a library to support SOAP+WSDL correctly "is going to be ton of work". And regardless of whether SOAP is too complex or not, it is becoming the de facto standard for web services integration schemes-- why? Because it's supported by Java, C#, Ruby, PHP, etc. -- but not by Perl, in any meaningful sense.

Reading the unanswered questions on the SOAP::Lite mail list is such an exercise in unmitigated pain, it makes we wish I had the skills and the time to tackle this project, or even start it.

But what really motivated my post is that my company has several large customers who use Perl SOAP clients to access our API. We are improving that API quickly, and we are trying to avoid recommending to our customers that they port their Perl SOAP client code to Java or Ruby.

But what really motivated my post is that my company has several large customers who use Perl SOAP clients to access our API. We are improving that API quickly, and we are trying to avoid recommending to our customers that they port their Perl SOAP client code to Java or Ruby.

Why not implement example Perl clients to show them how to do it?

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

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.

In my opinion, there are two sides. One, I agree that SOAP::Lite is in desperate need for a cleanup. However, it does work for many applications. On the other side, it is not providing a high enough level interface for my taste: you have to understand too much of the horrible dark corners of the schema, wsdl, and soap specification.

Because I wished for a much more perlish interface, I started XML::Compile a few months ago. On the moment, it does understand schema's quite well. It also does collect information from WSDL files, but does not translate that to SOAP.

My development version has a partial SOAP implementation. On the moment only document/literal. There are quite some bits left to complete, which holds me back from releasing it. Especially, the connection between WSDL extracted data and the actual SOAP messages.

So: I expect Perl will soon have a full standard-compliant SOAP implementation with an extremely simple application interface. Keep an eye on new XML::Compile versions, released in the coming weeks. If you like to have a preview, then don't hesitate to ask.

Anyway, in the end it was maybe a week or two's worth of work so I'd imagine it wouldn't be very hard to start up a project. I'd be interested in contributing if this does go ahead.

Since your post, the SOAP::Lite folks have posted this call for participation in a reworking of the module:

http://www.soaplite.com/2007/01/state_of_the_so.html

Maybe you could help them out?