I thought that you are generally expected to write your WDSL by hand, that the generators don't work. To get SOAP on *my* Fedora Core 4 desktop, I typed cpan SOAP::Lite and it just worked. That is, all the tests that I expected to pass. If you look at what's failing, it's things like "someone else's host has changed" so now the test doesn't pass. You can rerun your tests w/o doing the public testing and will likely see that it works ok. If not, file a bug on http://rt.cpan.org.

I thought that you are generally expected to write your WDSL by hand, that the generators don't work.

Well, some generators work ... but that's not necessarily a good thing.

The problem is, not all languages implement their data structures in the same manner -- most modern languages have a concept of an associative array of some sort ... but is a struct, a dict, a mapping, or a hash? Are any of those even the same thing? Does it support multiple values for a given key? Does it require a specific order? Does it allow elements to be missing?

It seems like a rather stupid thing, but what works in one language doesn't work in other languages. The solution is easy -- write the specification in something that doesn't deal with implementation details, and then force the language to implement the given specification.

So, write the WSDL first, then if you want to use some sort of auto-generator, use it to help you set up your functions/methods/subroutines/whatever they're called in the given language.

If you want to know more -- lurk on the SOAPBuilders mailing list for a while, or look for the various SOAP Interop testing, or search for 'SOAP impedence error'

I thought that you are generally expected to write your WSDL by hand, that the generators don't work.

I thought so too, which seemed really odd since .NET has the WebMethod attribute which sets up some automagickal WSDL/webservice thing that does what you need to expose your code as a webservice.
Example: Creating web services with .Net and Visual Studio

Example:

[WebMethod]
public string greet( string name ) {
  return "Hello, " + name;
}
[download]

The POD sections that Pod::WSDL looks for are pretty much along the same lines.

=begin WSDL

_IN name $string
_RETURN $string

=cut

sub greet
{
  my ($s, $name) = @_;
  return "Hello, $name!";
}
[download]

I typed cpan SOAP::Lite and it just worked.

If you're using Apache 1.3x that works just fine.

Java does that too. With the latest Java, you can easily expose your web service through simple annotation like @WebService, @WebMethod.

Perl's support of WSDL is really poor.

This is an unfortunate reality that has been true for years. Other languages have long had better and more-complete web services stacks for ages, largely because those languages have had commercial support. Microsoft has a vested interest in C# having a thorough SOAP/WSDL/etc. library available, as do Sun and IBM with regards to Java.

Perl, on the other hand, has never really had that degree of backing. Oh, there are plenty of companies with commercial interest in Perl, many (most?) of which have made contributions-- the funding that Ticketmaster poured in to the advancement of mod_perl is a great example of this, as well as the period of time Fotango was paying Leon Brocard to basically hack on big-P Perl.

But lower-level toolkits often get to a point where they're "good-enough" for the problem the author needs to solve, then the author has to go on to a new problem, Usually because that is what the author gets paid to do-- solve problems for whomever is writing the paycheck. SOAP::Lite is hardly alone in this-- the original SOAP package didn't get nearly as far in terms of functionality before it stopped being updated. I wrote my XML-RPC stack (RPC::XML) because Frontier::RPC2 wasn't being updated. And to be fair, I haven't had the bandwidth to keep up the pace on that project as much as I would like to.

Perl will have web service tools that are on par with Java and C# when someone has the money to invest in their development. That may be in the form of having enough personal wealth to go jobless for a year or so, or it may be a company that, like Ticketmaster and Fotango, feels that it is in their commercial interest to fund the work and give back to the Perl community.

(As an aside, there are a lot of things about SOAP::Lite that I would do differently, though that doesn't mean my version would be better. But if I had the time, or won the lottery, I would love to start a SOAP/WSDL/general webservices stack project. Alas, I don't have the time and I never get around to buying lottery tickets.)

SOAP::Lite is now a Sourceforge Project, for better or for worse, so you might consider working with the projects maintainers to improve support of the things that you find important.

For what it's worth, (and just to reinforce what others have said, ) doing automatically generated WSDL for services written in a dynamic language such as Perl is always going to be a problem as there is no way to know for sure either the parameters or the return types of a method in advance (without some kind of annotation such as POD or attributes), so yes most people seem to create the WSDL by hand or with tools such as the free Cape Clear WSDL editor.

/J\

Perhaps this would be a project better suited for Perl6?

Stronger typing and some level of abstraction would allow for automatic discovery of return types, parameters, etc.

Maybe, but Perl5 still needs SOAP support, and asides from money, theres no obstacles.

Have you had a look at the Writing, Installing, and Using Perl Modules section of the Tutorials of this site?

Although SOAP is not something I have used before, I am quite familiar with Writing, Installing and Using Perl Modules.

I am familiar enough that I know the magick incantation...

make
make test
make install
[download]

...doesn't work every single time. I know it is not always easy to get modules to compile correctly on all platforms, but I'm not exactly trying to get this stuff to run on a PocketPC or an X-Box. We're talking standard hardware + Fedora/Windows.

I know from reading p5p and mailing lists the kinds of hoops folks have to jump through to get Makemaker to do everything, and about Build.pm, CPANPLUS, etc.

<soap-box>

I have developed relatively large-scale projects spread across multiple servers, networks and operating systems and have always had this kind of trouble (not only with Perl).

Case in point: JavaScript::SpiderMonkey. SpiderMonkey would be *awesome* to have in several projects (embeddable scripting runtime, anyone?) but it seems that nobody can get this thing to compile. The CPAN Testers page doesn't help any either.

</soap-box>

On the other hand you have Inline::* - installs quickly, runs right out of the box (even on Windows) and does what its label says it does.

I know that the magick of being able to have 99% of everything work great is really nice, but I'm wondering what can be done to smooth out this last 1% of modules that have been difficult (or in the case of SpiderMonkey, nigh impossible) to install since Day One.

Case in point: JavaScript::SpiderMonkey. SpiderMonkey would be *awesome* to have in several projects (embeddable scripting runtime, anyone?) but it seems that nobody can get this thing to compile. The CPAN Testers page doesn't help any either.

Hmm, I see several bug reports, indicating others have been able to compile it. Have you tried reading the JavaScript-SpiderMonkey/INSTALL file? It helped me :)

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

That reply was me - I didn't realize I wasn't logged in.