SOAP::Lite for Perl

Intercepting the request and/or response before and after processing

A common question in the SOAP::Lite Newsgroup is about intercepting the request prior to handling, and the response prior to it being returned. SOAP::Lite v0.65 enables this on the client side pretty easily using the http_request and http_response methods on SOAP::Transport::HTTP::Client, but the server side is still a relative black art. I have friends who have used SOAP::Trace to log, or write to a file, the SOAP payload, but that is not entirely sufficient for all their needs. In future versions, SOAP::Lite will introduce the concept of handler chains, similar to Java Servlets, but for now, one still needs to do a little more work. The following code sample shows how one can extend SOAP::Transport::HTTP:CGI to intercept both the HTTP request and the HTTP response prior to it being processed and/or returned respectively.

Setting HTTP Timeouts for a SOAP client

The HTTP layer is abstracted away from the developer in SOAP::Lite. But knowing a few simple things about how SOAP::Lite was written can help open up a lot of functionality. For example, many users are not clear about how to set the HTTP timeout for a given request. Let's take a look at some sample code that allows a user to do this:

my $soap = SOAP::Lite ->uri($uri) ->proxy($proxyUrl, timeout => 5 ); print "timeout: ".$soap->proxy->timeout."\n"; $soap->proxy->timeout(100); print "timeout: ".$soap->proxy->timeout."\n"; print $soap->c2f(SOAP::Data->name('temperature' => 100));

This code works because SOAP::Lite->proxy returns an instance of the current transport layer/client. And in SOAP::Lite, the HTTP client transport layer (SOAP::Transport::HTTP::Client class) extends LWP::UserAgent. Therefore, all methods available in LWP::UserAgent are also available to users of SOAP::Lite's SOAP::Transport::HTTP::Client class. Which includes the timeout subroutine.

Dispatching requests to modules

In my work going through the SOAP::Lite code base fixing bugs and what not, I ran across an old email thread on the newsgroup asking about a fault that their client kept receiving from a SOAP Server written in Perl:

Failed to access class (Majordojo:TemperatureService): syntax error at (eval 123) line 1, near "require Majordojo:"

The root of the problem stems from the fact that the SOAP Action header, and/or the namespace of the method being invoked uses a URI format that confuses SOAP::Lite. In this case the URI is urn:Majordojo:TemperatureService. SOAP::Lite is not crazy about this format because when it tries to import the module Majordojo:TemperatureService it fails because it is not a valid module name. The call was failing because the server written in Perl was using SOAP::Lite default dispatch methodology, or the simplistic dispatch-to() subroutine.

SOAP::Lite version 0.65 is coming!

It has been over a year since the last release of SOAP::Lite. It is shameful, I know. But recent events have found me a little, how shall we say, "unemployed" and thus having a little extra time. I have been working like mad going through the bug list, and integrating a completely revised set of man pages and documentation, thanks to the generous writings of Randy J. Ray, author of Programming Web Services with Perl, and the contribution of Appendix B from the aforementioned book by O'Reilly. Many thanks to them. In any event, I am waiting on some final legalese from Oreilly, and when I get the final "ok" I will be checking my sources into CVS, and start my testing process. Read on to learn more about what features will be in the next release.

How to Access Nested SOAP Body Element

It is always appreciated when someone from the developer community gives something back. Even the simplest things, like an informative and helpful post to a newsgroup is invaluable, and software maintainers like myself, can only be incredibly gracious when it happens. This article was contributed by Mahesh Gadwal.

DIME support is coming!

Domingo Alcázar recently contacted me about DIME support in SOAP::Lite. I respond to requests like these all the time, and flippantly replied, "no, SOAP::Lite doesn't support DIME yet. I don't suppose you want to implement DIME support... do you?" A couple weeks later, Domingo did his first informal code drop, and now the Perl community will soon have access to DIME-tools and built-in DIME support into SOAP::Lite. Once his code is integrated, I will issue a new release of SOAP::Lite post-haste. Read on for more of what will be in that release...

Building an Array of Objects (manually)

I find myself feeling a little guilty as I write this, because I must sing a refrain that is all too familiar in a lot of my posts to the SOAP::Lite newsgroup, but building complex types in SOAP::Lite is a little challenging - certainly more challenging that your typical SOAP toolkit. However, this will hopefully be improved when SOAP::Lite v0.65 is released. So bare with me. In the meantime, if you want to build an array that other toolkits will parse, try a variant on the following code...

Programming Web Services with Perl website

Randy J. Ray, author of Programming Web Services with Perl, sent me a link a long time ago to a website he maintains dedicated to the book he wrote. It is an excellent resource for anyone who has read the book.

Persisting SOAP Headers

Well behaved SOAP services must persist and proxy SOAP headers not addressed to them. Unfortunately, SOAP::Lite does not do this for you automatically, so you must do it yourself. You can find a a little write up on how here.

How to Persist SOAP Headers in SOAP::Lite

I discovered recently that SOAP::Lite isn't necessary well-behaved when it comes to conforming to SOAP intermediary requirements. According to the spec, SOAP services must ignore headers not addressed to them and must pass them along untouched in any response they deliver. Now most developers don't need to worry about this because this capability is only relevant to people invoking SOAP intermediaries. However, at Grand Central where I work, we use SOAP intermediaries all the time; in one scenario, we were calling a Web Service I built using Perl, but it did not persist SOAP Headers properly. So, I wrote some code to address the problem, and now it works as the SOAP spec requires.