drewbie has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,

Long time gone, but I'm jumping into the world of web services at $work and need some advice. We're putting together an SOAP-based API and I have lots of questions about best practices for generating the SOAP responses. The platform is still open for discussion, but leaning towards Catalyst + Catalyst::Controller::SOAP + (XML::Compile::SOAP or SOAP::WSDL). The plan was to use SOAP 1.1 and WSDL 1.1.

Clients are very straightforward since we'll be publishing WSDL files, and XML::Compile::SOAP and SOAP::WSDL both seem to be work nicely out of the box. The docs are generally good for both, especially considering the large amount of functionality. We'll be creating a simple reference platform that will consume the services as a testbed, so client support is important.

The server side is not so straightforward. Perhaps the first question is: Are people writing SOAP servers with perl? Googling doesn't find much in recent history. I had been leaning towards XML::Compile::SOAP, but took a second look at SOAP::WSDL and was happy with the results from it too. Both support auto-configuration from a WSDL file (a must-have feature). And both have plans for better server support in the future. But I think Catalyst::Controller::SOAP will do the trick as long as I can generate a valid XML response to match the schema. I'm not even considering SOAP::Lite because of it's poor WSDL support and general slowness.

Method dispatch support for document/literal in Catalyst::Controller::SOAP seems to be missing so far. I hacked in support to look at the SOAPAction HTTP header but later read it's optional so I guess we'd look at the first element within the <Body> for a better approach. The wrapping of the response in the SOAP envelope looks useful as well.

Anyway, I'm rambling now, but I'd appreciate any advice you may offer.

Drew

Replies are listed 'Best First'.
Re: State of SOAP/WSDL support
by locked_user sundialsvc4 (Abbot) on Feb 26, 2008 at 19:19 UTC

    SOAP::WSDL is currently undergoing a substantial upgrade. Version 2.00 is available as a “developer release.” (Which means that you must ask CPAN to install the .gz file instead of simply using the package-name. This is described in perldoc CPAN.)

    This new version appears to be extremely powerful and complete, and while I did encounter right-away a very complex WSDL schema that it didn't understand, the developer immediately began working on the issue and now reports that he has resolved this in the SVN version. (I haven't pursued it yet.)

    The general strategy of “compiling” seems to be a good one, for efficiency reasons, as it is (relatively speaking) time-consuming to process a WSDL. (This strategy auto-generates Perl code and data-structures which conform to the intended format.)

    It is interesting that you decry SOAP::Lite because, as far as I know, SOAP::WSDL is built on top of it. Benchmarking your proposed strategy under real-world load conditions is obviously critical but you've clearly got a good grip on that.

      I was testing the 2.0 version of SOAP::WSDL, so I have an idea about what it can do. That version doesn't use SOAP::Lite under the covers (though it emulates the API to a degree) hence my comment. :-) One thing I immediately ran into with SOAP::WSDL was the need to combine my definitions, schema, and service files into 1 (which took <5 min to fix a couple namespace definitions). After that it ran and was able to generate both the client and server perl modules. XML::Compile processed my wsdl definition fine once I told it about where the other 2 were, so it handles the <import> but simply chooses not to be network aware. The author mentions this as a design decision in the docs.

      What wasn't immediately obvious to me was how I would use those resulting classes on the server side. If I understand things correctly, I could use the Interface class and go from there.

      One the one hand I do like that it autogenerated all the code & modules for me. But I wonder about the possible overhead that creates (perhaps none?). I know that XML::Compile takes a completely different approach to the efficiency problem by parsing the WSDL and returning a code ref for each operation (my $call = $wsdl->operation('MyFoo'); IIRC). The idea there was to call operation() once and save the resulting object. If you're getting a fresh object every time then clearly that approach will not scale like SOAP::WSDL.

      Benchmarking SOAP::WSDL and XML::Compile::WSDL11 using their optimum setup environment would be my next step if I had the time. :-)

[reply]
Re: State of SOAP/WSDL support
by Herkum (Parson) on Feb 26, 2008 at 19:13 UTC

    I had written a SOAP::Lite client/server application. SOAP::Lite side was not so bad as long you did not use its custom serializer with custom XML docs.

    The thing about SOAP is that it just encapsulates a message, a request for a service. What that request should look like and how complicated your SOAP server depends entirely upon you. I don't think that Perl is any worse than any other language. As far as data sharing of XML documents, Java had some exceptional tools but they may or may not be what you are looking for.

[reply]
Re: State of SOAP/WSDL support
by rahed (Scribe) on Feb 27, 2008 at 19:55 UTC
[reply]
      I'll check the SOAP::Lite mailing list, but my understanding was that SOAP::Lite has poor support for WSDL and document/literal format. Both of these are very important to my project, so poor support makes S::L a non starter. And last time I checked (admittedly a long time ago) S::L was quite slow, on the order of a few requests per second.
[reply]

Back to Seekers of Perl Wisdom