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...
Re:Always with the naming
Aristotle on 2008-02-26T03:44:25
Reminds me of Pete Lacey: The S stands for Simple.
Re:Always with the naming
slanning on 2008-02-26T13:15:31
That's a good one. And sad...
:( Re:Always with the naming
Matts on 2008-02-26T14:28:17
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.Re:Always with the naming
kaare on 2008-02-26T21:17:10
Heh. Exactly my feeling:-)
I gave up understanding why namespaces are called http://something/ (apparantly Microsoft calls them http://tempuri/ by default). It doesn't point to anything, and it's generally confusing.Re:Always with the naming
Aristotle on 2008-02-26T21:40:32
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 anything at the address in question.
Re:I'm in the same boat!
kaare on 2008-02-27T10:58:38
Email on the way:-)
