Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

kaare (663)

  (email not shown publicly)

Journal of kaare (663)

Monday February 25, 2008
02:07 PM


[ #35754 ]

Recently I had to implement a SOAP client and a SOAP server. Well, I didn't actually have to, I volunteered. Shows how stupid I am.

I will start with the conclusion. Note that this is my opinion, others may disagree, but Perl and SOAP don't match. Not quite yet, at least. I mean, SOAP is designed by a committe and adopted by the Java community and Microsoft. I can't imagine anything more developer unfriendly. In the other corner we have our more or less relaxed “We can do it” Perl. But I found hope. More on that later.

My last visit to SOAP in Perl land was some 5-6 years ago when the World was young and Perl land was unstructured as Hell. (Actually I don't know if Hell is unstructured or not, perhaps it's written in Java. That would make sense, I guess).

But I digress. At that time there was only one real choice if I recall, SOAP::Lite. The “Lite” in SOAP::Lite is a misnomer. Perhaps it started out as Lite, but now it just feels big and bumpy.
Actually, as far as I can see, SOAP::Lite really only supports RPC/Encoded. The documentation mentions partial support for Document/Literal but I believe it's not really there.

RPC/Encoded doesn't really fit the bill if you want well structured schema based remote actions, so for this Catalyst project, so I was aiming for RPC/Literal. There's also Document/Literal, but RPC/Literal fits almost exactly together with Catalyst's Component model.

I've already complained about SOAP::Lite, but fortunately there's a new module that can compile schemas and apply them to SOAP. XML::Compile from Mark Overmeer seems like a fresh breeze of air and just understands the SOAP protocol.

Daniel Ruoso has built Catalyst::Model::SOAP and Catalyst::Component::SOAP on top of XML::Compile in order to help build Catalyst applications easier. I would add that the Model part feels almost finished. The Controller bit needs a lot in the SOAP Envelope packing/unpacking. But at least it got me going.

Developer pain.
Some of you may know already – and somewhere in a dark spot in my mind I had it stored – that you need a WSDL file when doing SOAP. Wouldn't it be nice to have a tool to write it for you? My hopes where high when I found Pod::WSDL on CPAN. It's a really nice idea to embed the parameter and type informaion in the methods Pod. But again, Pod::WSDL can only output RPC/Encoded.

Now, WSDL files are not hard to hand write if you know what you are doing, it's just a tedious and error prone task. So if you have some spare time, pick up Pod::WSDL (it's unmaintained at the moment) and add RPC/Literal and Document/Literal. The source code looks well laid out and easy to understand. Please implement a more economic solution for complex types. If each complex type really relly needs its own package, at least make Pod::WSDL find it within one file.

As an added benefit, by implementing SOAP in the Catalyst application I got rid of Catalyst::Plugin::XMLRPC. That's a good thing because it had a mysterious habit of leaving all the requests as open files. I mean A LOT, it could be thousands, depending on how busy the 'webservices' bit was.

I have plans to extend Catalyst::Controller::SOAP with some SOAP Envelope unpacking and response handling based on the wsdl file. When I get time...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I guess SOAP::Lite is as lite as SOAP is simple and object oriented.
    • Reminds me of Pete Lacey: The S stands for Simple [].

      • That's a good one. And sad... :(

      • A number of years ago I did a presentation called "Why SOAP Sucks, Why SOAP Sucks!". At the start of it I had enough paper to contain all the specs required to fully understand SOAP (XML, SOAP, WSDL, UDDI, XML-Schemas, and possibly something else)... The entire thing comes to just over 1000 pages.

        Anyone who can understand all that and build an interoperable system deserves a medal. Sadly there is nobody who does.
      • Heh. Exactly my feeling :-)

        I gave up understanding why namespaces are called http://something/ [something] (apparantly Microsoft calls them http://tempuri/ [tempuri] by default). It doesn't point to anything, and it's generally confusing.
        • Because namespaces are URIs, and that in turn is because those are (generally) globally unique identifiers. That’s all. In the context of namespaces the URI doesn’t have any meaning beyond being a unique identifier. That’s fine, as URIs don’t have to be retrievable, even those with schemes you’re used to thinking of as retrievable, such as “http:”. You can use any other scheme though. For namespaces I like to use “tag:” when I don’t plan to put any

  • Your ears must have been burning, because only a few hours ago I posted a question about SOAP on perlmonks []). I'm also planning to use Catalyst::Controller::SOAP and XML::Compile, and had the exact same questions about generating the server side response. I'd love to collaborate with you on the C::C::SOAP changes you mentioned, if you like. Email me at drew at drewtaylor dot com.
    "Perl users are the Greatful Dead fans of computer science." --slashdot comment