The sad state of SOAP and Perl

I'm looking to expose some Perl programs I have as web services via SOAP.

The trick is, I would like to expose them as *real* web services - WSDL included.

I am aware that this is not the first time this question has come up - I am familiar with the SOAP and SOAP::Lite modules. I have checked out UDDI, Pod::WSDL, WSDL::Generator and SOAP::WSDL.

UDDI does not make test on Win32 or Linux (Fedora 4).
WSDL::Generator does not get past make test on Win32 or Linux (Fedora 4).
Pod::WSDL builds correctly on Win32 (requires v5.8.5 but my Linux has v5.8.3)

I was unable to find a single module in CPAN for BPEL or Xlang.

ebXML exists, but it has a dependency on XML::Xerces. Installing XML::Xerces via RPM from rpmfind.net does not set up the variables XERCESROOT, XERCES_LIB, XERCES_INCLUDE and XERCES_CONFIG, so XML::Xerces still won't install even after installing the Xerces library rpm. Apparently you have to compile Xerces.

So I set out to install Xerces from the source available at http://xml.apache.org.

Fedora 4 does not include autoconf or g++, and cpp doesn't understand the -c directive, so it bails out. At this point I decided to write off ebXML as well.

Installing the SOAP module via CPAN tries to install Apache (not Apache2).
After a successful SOAP install (via CPAN) the following happens:

[root@mailer2-sb root]# perl -MSOAP -e 'print "Hello, with SOAP!"'
Can't locate SOAP/Transport.pm in @INC (@INC contains: ....
[download]

So what else would you do?

cpan> install SOAP::Transport
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Mon, 10 Apr 2006 18:46:07 GMT
Warning: Cannot install SOAP::Transport, don't know what it is.
Try the command

    i /SOAP::Transport/

to find objects with matching identifiers.
[download]

Running that command, one can glean that SOAP::Transport is part of SOAP::Lite - along with over a dozen other distributions. I set out to install SOAP::Lite.

SOAP::Lite did not test correctly. Most tests that involved server tests failed. I installed with force. A quick test from the command line showed that SOAP::Lite loads fine - good enough for me.

At this point I have spent almost an hour just installing modules, most of which did not work at all. I could understand if I were running some fringe OS or a minimal install, however, the machine I am using has Fedora Core 4 with everything installed - not exactly a fringe case.

Pod::WSDL turned out to be Really Great Stuff. So having that working, the next step is a mod_perl handler that would serve the WSDL dynamically. Sure, I could just dump the WSDL to a static file whenever I update my Perl modules, but what fun would that be?

package MyApp::WSDL;

use strict;
use Pod::WSDL;

sub handler : method
{
  my ($s, $r) = @_;
  
  my ($package) = $r->uri =~ m/^\/([^\?]+)/;
  $package =~ s/\//::/g;
  
  my $pod = Pod::WSDL->new(
    source            => $package,
    location          => "http://$ENV{HTTP_HOST}" . $r->uri,
    pretty            => 1,
    withDocumentation => 1,
  );

  print "content-type: text/xml\n\n";
  print $pod->WSDL;
  return 0;
}# end handler()

1;# return true:
[download]

Then on top of that I figure Apache2::SOAP would do the trick.

There is no Apache2::SOAP ppm from ActiveState.
Apache2::SOAP requires ModPerl::MM.
ModPerl::MM is part of the mod_perl2 distribution.

**If you're using Win32 to run this**, and you already have had the good fortune of plowing your way through Google, httpd.apache.org, PerlMonks, per.apache.org, and perhaps several others just to find a working Apache2 + mod_perl2 + SSL binary (who has time to compile it??) then Apache2::SOAP will work great right out of the box.

If you are not one of the fortunate, then sadly you're on your own.

This task has opened my eyes to the world of problems associated with installing Perl software, especially when it links against external libraries. I didn't even get far enough with this to *do* any SOAP - and I have been dinking with this most of the morning.

I think it's time we put together even 1 page that lists a how-to document that would get indexed by Google and point some folks in the right direction.

Any takers?

Moved from Seekers of Perl Wisdom to Meditations by planetscape

Comment on The sad state of SOAP and Perl Select or Download Code

Replies are listed 'Best First'.

Re: The sad state of SOAP and Perl
by diotalevi (Canon) on Apr 12, 2006 at 21:59 UTC

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.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]

Re^2: The sad state of SOAP and Perl

by jhourcle (Prior) on Apr 13, 2006 at 02:43 UTC

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'

[reply]

Re^2: The sad state of SOAP and Perl

by jdrago_999 (Hermit) on Apr 12, 2006 at 23:10 UTC

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

WebMethod

Creating web services with .Net and Visual Studio

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

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

[reply]
[d/l]
[select]

Re^3: The sad state of SOAP and Perl

by Anonymous Monk on Apr 13, 2006 at 00:26 UTC

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.

[reply]

Re^4: The sad state of SOAP and Perl

by Anonymous Monk on Apr 13, 2006 at 03:21 UTC

Re: The sad state of SOAP and Perl
by rjray (Chaplain) on Apr 13, 2006 at 06:15 UTC

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

--rjray

[reply]

Re: The sad state of SOAP and Perl
by gellyfish (Monsignor) on Apr 13, 2006 at 10:20 UTC

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\

[reply]

Re^2: The sad state of SOAP and Perl

by jdrago_999 (Hermit) on Apr 13, 2006 at 14:10 UTC

[reply]

Re^3: The sad state of SOAP and Perl

by Anonymous Monk on Apr 13, 2006 at 22:58 UTC

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

[reply]

Re: The sad state of SOAP and Perl
by Anonymous Monk on Apr 13, 2006 at 02:44 UTC

Writing, Installing, and Using Perl Modules

Tutorials

[reply]

Re^2: The sad state of SOAP and Perl

by Anonymous Monk on Apr 13, 2006 at 03:19 UTC

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

make
make test
make install
[download]

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.

[reply]
[d/l]

Re^3: The sad state of SOAP and Perl

by PodMaster (Abbot) on Apr 13, 2006 at 07:35 UTC

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.

bug reports

JavaScript-SpiderMonkey/INSTALL

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.


go ahead... be a heretic
	PerlMonks